Linux服务崩溃后能否自动恢复，关键在于重启策略是否合理：需区分服务类型配置Restart选项，设置StartLimitIntervalSec和StartLimitBurst防雪崩，并通过systemctl show、kill模拟和journalctl验证生效。
Linux服务崩溃后能否自动恢复，关键不在“能不能重启”，而在于“该不该重启、怎么重启、重启几次、何时停手”。systemd 提供的不是简单的开关，而是一套可配置、可约束、可验证的稳定性设计框架。
看懂状态，别被“active (running)”蒙蔽
执行 systemctl status nginx 显示 active，并不代表请求能响应、端口在监听、worker 正常工作。常见假象包括：
- master 进程存活，但所有 worker 已退出（用 ps aux | grep nginx 查看 worker 数量）
- 配置错误导致监听失败，日志里有 bind: Address already in use 或 invalid number of arguments
- 依赖服务未就绪（如数据库连不上），服务启动后几秒内主动退出，状态短暂显示 active 后变 failed
重启策略要匹配服务类型
不是所有服务都适合 Restart=always。选错策略可能掩盖问题，甚至引发雪崩：
- 无状态 Web 服务（Nginx、API 网关）：可用 Restart=on-failure + RestartSec=3，避免因 OOM 或 SIGSEGV 后立即重试失败
- 有状态服务（PostgreSQL、Redis）：优先用 Restart=on-failure，禁用 always；加 ExecStartPre=/usr/bin/pg_isready -q 预检依赖
- 批处理或定时任务类服务：考虑 Restart=no，改用 timer + oneshot unit，由调度逻辑控制重试
必须设防：频率限制与资源兜底
没有限制的自动重启等于给故障开绿灯。两项配置缺一不可：
- StartLimitIntervalSec=600：10 分钟为一个统计窗口
- StartLimitBurst=3：窗口内最多重启 3 次；超限后 systemd 将标记为 start-limit-hit 并彻底停止尝试
- 额外加固：加 MemoryLimit=512M 和 RestartSec=10，防止内存不足时高频拉起耗尽资源
验证比配置更重要
改完配置不验证，等于没改。三步快速确认是否生效：
- 查当前策略：systemctl show myapp.service | grep -E "Restart|StartLimit"
- 模拟崩溃（测试环境）：sudo systemctl kill --signal=SIGSEGV myapp，观察 journalctl -u myapp -f 是否在 RestartSec 秒内出现新 Started 记录
- 触发限频（连续 kill 4 次）：确认第 4 次后状态变为 failed (start-limit-hit)，且 journal 中提示 “Start request repeated too quickly”
