3.3 应用商店安装失败与容器起不来

先给一个判断

应用安装失败，90% 是三类原因：镜像拉不下来、端口/目录冲突、参数填错。 容器起不来则多半是配置或资源问题。这几件事的答案都在两个地方写着——安装时的任务日志，和容器自己的日志。打开它们，问题就解决了一半。

现象：安装失败长什么样

应用商店点【安装】后会进入参数填写页面，确认后弹出安装日志窗口。失败的表现：

关键习惯：安装日志窗口不要急着关，等它跑完看结论。关早了再想看，得去 日志审计 → 任务日志 里翻。

一个小技巧：装大应用（镜像几百 MB 起步）之前，先确认网络和磁盘都没问题：df -h / 看剩余空间够不够。装到一半磁盘满了，不光这次失败，半拉子文件还占地方。

定位：日志怎么看

第一步：任务日志。 日志审计 → 任务日志，找到这条安装任务，打开详情看完整输出。注意区分两类信息：

• 拉镜像的输出失败：一般是网络 / 镜像仓库问题；
• 容器启动阶段失败：一般是参数、端口、目录问题。

第二步：容器日志。 已安装列表 → 应用详情，或者直接在服务器上：

# 看所有应用容器的状态（Exited 的就是死掉的）
docker ps -a --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"

# 看某个容器为什么死（容器名按实际替换）
docker logs --tail 200 容器名

第三步：状态同步。 已安装应用列表里有个【同步】按钮，作用是更新应用状态，让它和系统实际状态一致。有时候“应用显示异常”只是状态没刷新，点一下同步可能就好了，别直接重装。

一个高频误判：应用显示异常，其实是状态没刷新。先点【同步】，再决定要不要“大动干戈”。很多人在这里把应用重装了一遍，后来发现它本来就是好的——重装还顺带丢了手改的配置。

先认识三个容易混淆的操作

分不清重建和重装是事故的常见来源。重建是“用原配方重新煮一锅”，数据卷还在；卸载重装是“锅都扔了”。不确定的时候用【重建】而不是卸载。

修复：镜像拉不下来

症状：安装日志里一直处于拉取镜像的状态，或者报连接超时。

# 手动测试某个镜像拉不拉得动（镜像名按实际替换）
docker pull 应用镜像名:标签

修复：端口或目录冲突

症状：安装日志里报端口/地址已被使用，或者容器启动后立刻退出。

# 查端口被谁占了
ss -ltnp | grep 端口号

# 查存储卷/目录占用
ls -ld /opt/1panel/apps/应用名/

处理：安装参数里把端口换一个空闲的；如果是旧应用残留占着，先在已安装列表里彻底卸载（必要时用强制删除），再重装。

一个经典坑：之前装过同一应用、卸载时只删了容器没删数据，重装的时候配置对不上。卸载应用有“删除备份”选项，还会删除容器和配置文件——卸载前确认数据不要了。

另一个经典坑：应用装在 1Panel 里、又手动用 docker run 在外面跑了一个同镜像的容器，两边端口或数据卷打架。1Panel 管理的应用，用 1Panel 的界面操作；外部的容器，归外部管，别两套混着来，状态不同步是早晚的事。

修复：参数填错

应用参数（数据库密码、管理员账号、端口等）填错，安装过程可能直接失败，也可能装完之后应用行为异常。安装时页面会提示哪些是必填项；不确定的参数鼠标移到说明上看提示，别按默认值瞎猜。

一个边界：安装时的“高级设置”里可以编辑 compose 文件。手动改 compose 是双刃剑——能解决特殊需求，但改错了应用起不来，面板提示的报错也不一定直白。改之前先备份原文件。

修复：容器起不来/反复重启

容器状态是 Exited 或 Restarting，按这个顺序查：

1. 看日志（docker logs --tail 200 容器名）——日志第一句往往就是答案，比如“配置文件语法错误”、“权限不足”、“无法连接依赖”；
2. 看依赖——很多应用依赖数据库，数据库不健康，应用容器就跟着重启；
3. 看资源——内存不足被 OOM 杀的容器会反复重启：

# 看有没有 OOM 记录
dmesg | grep -i "out of memory" | tail -5

1. 看配置——应用参数页面可以修改部分参数；数据库类应用配置文件路径参见 3.1 节。

2. 看文件权限——数据卷挂载进容器后，如果宿主机目录的属主和容器内运行用户对不上，应用一写文件就崩。表现通常是日志里一堆 “Permission denied”。处理办法见 5.3 节。

修复手段的优先级：先【重启】→ 不行用【参数】改配置 → 再不行【重建】。重建会删除容器重新创建，配置了持久化的应用数据会保留（官方原文），但直接改过容器内其他文件的修改会丢失——所以重要的改动要走参数或 compose，不要进容器里手改。

一个完整的复现与修复

现象：安装一个应用，进度卡在 60% 不动，最后报失败。

排查过程：

1. 打开任务日志，发现一直停在拉取镜像那一步，网络层超时；
2. 在服务器上手动 docker pull 同一个镜像，同样超时——确认是镜像拉取问题；
3. 检查网络和镜像加速配置，修正后重试。

修复：网络问题解决后重新安装，应用状态正常。

第二个例子（容器起不来）：

现象：应用显示已安装，但状态异常，访问不了。

排查过程：

1. docker ps -a 发现容器是 Exited；
2. docker logs --tail 100 显示连不上数据库；
3. 原来是装应用时让它自动建库，但数据库实例刚改过 root 密码，应用拿着旧密码连；
4. 在应用【参数】里更新数据库连接信息，重启应用，恢复。

复盘要点：多个组件联动时，改了一个的配置，要想着联动更新另一个。改数据库密码是最容易引发连锁反应的操作之一。

验证：确认应用真的好了

1. 已安装列表状态正常，docker ps 里容器 Up；
2. 应用自身有健康检查的，过几分钟确认没再重启：

# 看容器启动时间，确认没有反复重启
docker ps --filter "name=容器名" --format "{{.Names}} 状态:{{.Status}}"

1. 实际访问应用，走一遍核心功能（登录、保存、读取），而不是只看首页。

只看首页是自欺欺人——很多应用首页是静态的，首页能开不代表数据库读写都正常。最少要试一次“会写数据”的操作（发条文章、存个设置），才能真正确认应用恢复了。

本节要点

• 安装失败看任务日志，容器死了看容器日志，状态不对先试【同步】；
• 分清重启、重建、卸载三个操作的破坏力等级；
• 镜像拉不下来查网络；端口冲突 ss -ltnp；参数按页面提示填；
• 修复顺序：重启 → 改参数 → 重建；重建保留持久化数据、丢失容器内手改；
• 容器反复重启先怀疑依赖（数据库）和 OOM；
• 改了数据库密码，记着联动更新应用里的连接信息；
• 状态显示不对，先【同步】再谈修复。

应用安装与管理的官方说明见 1Panel 官方文档：应用商店，以官方文档为准。应用商店的应用由官方维护并持续更新，遇到特定应用的安装问题，先看应用详情里的说明和任务日志，多数报错都能直接定位。

下一节：应用装好了，升级和迁移的坑在等着——数据无价，谨慎前行。