飞牛NAS Docker容器频繁重启：排查与修复

Docker 容器频繁重启，是飞牛NAS玩家绕不开的经典问题。它不像硬盘故障那样有刺耳的异响，也不像网络断连那样直接，但它以一种“薛定谔的存活”状态，让日志审查和排错变得异常煎熬——你刚打开容器日志，它恰好退出；你准备重启容器，它又自己活了过来。本文将从飞牛NAS（fnOS）的实际操作界面出发，结合命令行，为你梳理一套从“被动观察”到“主动修复”的排查流程。

一、先确认“重启”是真故障还是假象

在飞牛NAS的Docker管理界面，你看到容器状态在“运行中”和“已退出”之间反复横跳，这通常意味着容器进程的 PID 1 不断崩溃。但有一种例外是健康检查失败导致的“Unhealthy”状态，它并不会强制重启容器，只是显示黄色警告。因此，第一步永远是查看容器的退出码和重启策略。

SSH 登录飞牛NAS，执行：

docker ps -a --filter "name=你的容器名"

观察输出的 STATUS 列。如果显示 Restarting (1) 2 minutes ago，括号内的数字（如1、137、139）就是退出码，它直接指向了崩溃原因：

退出码 0 或 143：正常停止或手动停止，属于人为操作，不是故障。退出码 1：应用程序内部错误，最常见，通常是代码异常或配置缺失。退出码 137：被强制杀死，通常是 OOM（内存溢出）或手动 docker kill。退出码 139：段错误，通常是容器内程序访问了非法内存地址，多见于底层库冲突。

二、三步定位法：从日志到资源，层层递进

1. 捕获“临终遗言”——查看容器日志

容器崩溃后，日志会保留，但滚动速度极快。我们需要在它重启的间隙抓取日志。建议不要用飞牛NAS的图形化日志窗口，因为刷新太快。直接在SSH下执行：

docker logs --tail 100 --timestamps 你的容器名

如果日志里反复出现 panic、segfault、Out of memory 或 Error: connect ECONNREFUSED 等关键词，基本就能锁定方向。例如，常见的 Error: listen EADDRINUSE 说明端口被占用，你需要修改容器映射的宿主机端口。

2. 检查资源配额——内存和CPU是重灾区

飞牛NAS默认对容器不做资源限制，但如果你在创建容器时手动设置了内存上限，容器超出该上限就会被内核 OOM Killer 杀死，表现为退出码 137。此时执行：

docker stats --no-stream

查看该容器的 MEM USAGE 是否一直逼近上限。如果确认是OOM，你有两个选择：在飞牛NAS的容器编辑界面调高内存限制；或者优化容器内应用的内存占用（例如JVM堆内存参数）。

3. 验证存储卷权限——挂载目录的隐藏坑

很多容器（如MySQL、Redis）在启动时需要读写挂载的存储卷。如果挂载目录的权限不足或属主不对，容器会在启动瞬间崩溃。飞牛NAS的共享文件夹默认属主是 admin，但容器内进程通常以 root 或非root用户运行。

在SSH下执行：

ls -ld /vol1/你的存储卷路径

如果权限不足，直接修改属主为容器内用户（或干脆设为宽松权限）：

sudo chmod -R 777 /vol1/你的存储卷路径

注意：此操作仅限测试环境，生产环境建议使用 chown 指定正确的UID/GID。

三、针对不同退出码的修复实战

场景A：退出码1，日志提示“数据库连接失败”

这通常是容器依赖的另一个服务（如MySQL）还没就绪。解决方案是给容器增加健康检查和依赖等待。在飞牛NAS的Docker Compose编辑界面，添加：

depends_on:
  mysql:
    condition: service_healthy
healthcheck:
  test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
  interval: 10s
  timeout: 5s
  retries: 5

场景B：退出码137，内存持续飙高

如果你用的是第三方镜像，可以在容器启动命令中加入环境变量来限制内存。例如Java应用：

docker run -d --name myapp -e JAVA_OPTS="-Xmx256m" ...

同时在飞牛NAS的容器设置里，将内存软限制设为 512m，硬限制设为 1g，避免直接打爆宿主机内存。

场景C：退出码139，疑似底层库冲突

这多发生在镜像架构与宿主机不匹配时。例如在飞牛NAS的 x86 架构上运行了 ARM 版镜像，或者镜像依赖的 glibc 版本过旧。此时建议更换官方镜像标签，优先选择 latest 或带 -alpine 的版本，并确保镜像平台为 linux/amd64。可以执行：

docker pull --platform linux/amd64 镜像名

四、终极手段：调整重启策略，避免无限循环

如果以上都无效，至少要让容器的重启行为可控，避免无限循环拖垮整个Docker守护进程。在飞牛NAS的容器设置中，将“重启策略”从“总是”改为“除非停止”。命令行对应为：

docker update --restart=unless-stopped 你的容器名

这样，当容器因错误退出时，Docker 会停止自动拉起，让你有充足的时间去分析日志，而不是看着屏幕上的状态闪烁干瞪眼。

五、一个容易忽略的细节：检查宿主机的磁盘空间

容器崩溃有时并非自身问题，而是宿主机 / 分区满了导致 Docker 守护进程无法写入日志或元数据。执行：

df -h

当 /dev/root 使用率超过90%时，优先清理飞牛NAS的回收站和Docker的悬空镜像：

docker system prune -f

这能瞬间释放大量空间，偶尔能意外解决容器反复重启的问题。

总结

容器频繁重启不是玄学，而是一场有迹可循的故障排查。记住“先看退出码，再查日志，次看资源，后查权限”的四步顺序，能让你少走一半弯路。飞牛NAS的图形化界面固然方便，但关键时刻，SSH命令行仍是穿透迷雾的最强武器。如果你的容器在修复后仍不稳定，不妨考虑放弃该镜像，改用官方原版或更活跃的社区维护版本——毕竟，稳定的服务比炫酷的功能更重要。