Linux 服务崩溃自动恢复方案

linux服务崩溃自动拉起应优先使用systemd守护机制，通过restart=on-failure等策略实现稳定重启，辅以健康检查、资源限制和watchdog增强可靠性，避免轮询或简单脚本兜底。

Linux 服务崩溃后能自动拉起，关键不是靠脚本轮询，而是用系统级的守护机制——systemd 是现代主流方案，稳定、简洁、原生支持依赖、重启策略和状态追踪。

用 systemd 设置自动重启

绝大多数服务（如 nginx、redis、自定义 Python 脚本）只需修改其 service 文件，启用 Restart 策略即可：

• 编辑服务单元文件：比如 /etc/systemd/system/myapp.service
• 在 [Service] 段添加：

  Restart=on-failure<br>RestartSec=5<br>StartLimitIntervalSec=60<br>StartLimitBurst=3

  表示：非正常退出时 5 秒后重启，1 分钟内最多尝试 3 次，超限则暂停

• 重载并启用：

  sudo systemctl daemon-reload<br>sudo systemctl enable --now myapp.service

处理“假死”或无响应进程

systemd 默认只监控进程是否退出，对卡死、高 CPU、OOM 占用等不敏感。可配合以下增强手段：

• 启用健康检查：在 service 文件中加 ExecStartPre=/usr/bin/curl -f http://localhost:8080/health || exit 1（适用于 HTTP 服务）
• 设置资源限制：加 MemoryMax=512M、CPUQuota=80%，配合 OOMScoreAdjust=-500 降低被 OOM Killer 杀掉的概率
• 用 watchdog：若服务支持（如某些 Go/Python 框架），开启内置 watchdog，并配置 WatchdogSec=30 和 Restart=watchdog

避免循环重启与日志排查

自动重启若没配好，可能陷入“启动 → 崩溃 → 重启”死循环，掩盖真实问题：

• 务必开启 journal 日志：用 journalctl -u myapp.service -n 100 -f 实时跟踪启动失败原因
• 区分重启类型：用 Restart=on-abnormal（跳过 exit code 0 的正常退出）或 on-watchdog 更精准
• 临时禁用重启调试：运行 sudo systemctl set-Property myapp.service Restart=no，再手动 start 观察

简单场景：没有 systemd 的轻量环境

在容器、嵌入式或旧版系统中，可用最小化方案替代：

• 用 supervisord：安装后写 conf，指定 autorestart=true、startretries=3，适合多进程管理
• Shell 循环兜底（仅临时/测试）：

  while true; do ./myserver || sleep 5; done

  注意：需搭配 nohup 或放入 screen/tmux，且无法感知资源异常

• 避免 crontab 轮询检测：精度低、开销大、易冲突，不推荐用于生产服务恢复