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 轮询检测：精度低、开销大、易冲突，不推荐用于生产服务恢复
