如何在Docker容器内管理守护进程服务实现故障自动重启

你遇到的僵尸进程残留、服务故障无法自动替换问题，核心原因是直接将 avahi-daemon 作为容器 PID 1 进程启动：Linux 系统中 PID 1 进程默认承担孤儿进程回收、信号转发的特殊职责，avahi-daemon 没有实现这套逻辑，子进程退出后无人回收就会变成 defunct 僵尸进程，自身故障退出后残留进程占住资源，新实例自然无法启动。
可以分两层配置解决，不需要大幅改动现有部署逻辑： #

1. 配置容器级自动重启策略 #

直接在 docker-compose.yml 对应服务段添加重启规则，实现容器级故障自愈：

• 配置 restart: unless-stopped：服务异常退出、宿主机重启时会自动拉起容器实例，仅当你手动执行 docker compose stop 时才会保持停止状态，是单服务场景最常用的重启策略。
• 不推荐使用默认的 no（无自动重启），也不建议无特殊需求用 always——always 策略下即使你手动停止了容器，宿主机重启后也会强制把服务拉起来。

2. 替换 PID 1 进程解决僵尸进程问题 #

必须给容器加合法的 init 进程作为 PID 1，才能从根上解决僵尸残留问题，根据你的部署复杂度选一个方案即可：

方案一：零额外修改，用 Docker 内置 init（单服务场景首选） #

直接在 compose 服务段加一行 init: true，Docker 会自动用轻量的 tini 作为容器 PID 1 进程，自动完成信号转发、僵尸进程回收，不需要修改原有镜像。
此时你仍然可以直接把 avahi-daemon 作为主启动进程，tini 会托管它的生命周期：avahi-daemon 故障退出时，tini 会自动清理所有残留的子进程，触发容器正常退出，配合上面的重启策略就会自动拉起全新的干净实例，不会有僵尸残留。

方案二：轻量进程托管（容器内多服务/细粒度重启需求选这个） #

如果容器内还要跑其他附属服务，或者不想服务一故障就重启整个容器，可以把轻量进程托管工具作为 PID 1 打包进镜像：

• 选 s6-overlay：面向容器设计的 init 套件，自带进程回收、服务托管能力，只需要写几行服务定义，就能配置 avahi-daemon 故障时直接在容器内重启，不用重启整个容器，恢复速度更快，天然无僵尸进程问题。
• 选 supervisord：配置门槛更低，写一份简单的 ini 配置指定 avahi-daemon 的启动命令、autorestart=true 规则，把 supervisord 作为容器入口启动即可，同样能完成进程托管、僵尸回收，适合已经熟悉 supervisor 的用户。

最小可用配置示例 #

version: '3.8'
services:
  avahi:
    image: 你自己的avahi镜像地址
    network_mode: host # avahi 依赖mDNS广播，一般需要用host网络
    init: true
    restart: unless-stopped
    # 原有卷挂载、环境变量、权限配置全部保留
    command: avahi-daemon --no-daemon # 必须加--no-daemon让服务前台运行，避免托管进程误判主进程退出

关键注意事项：无论选哪个方案，必须让 avahi-daemon 以前台模式运行，禁止它自己fork成后台守护进程，否则托管进程会误判主进程已经退出，触发不必要的重启或者直接退出容器。

内容的提问来源于stack exchange，提问作者tsvallender