进程频繁重启是系统反复尝试恢复的结果，需先通过journalctl查退出原因，再用dmesg确认oom killer干预，接着检查restart策略与资源依赖。
进程频繁重启不是服务“自己想活”，而是系统在反复尝试恢复——背后一定有明确诱因。关键在于分清是服务自身崩溃，还是被系统强制干预，再逐层定位。
先看 systemd 日志，锁定退出瞬间的线索
systemctl status 只显示当前状态，真正原因藏在 journal 里：
- 运行 journalctl -u your-service.service -n 100 --no-pager -o cat，聚焦最近 100 行，去掉时间戳干扰，快速识别错误关键词
- 重点留意：main process exited, code=killed, signal=SEGV（段错误）、status=137（OOM Killer 杀死）、Failed with result 'timeout'（启动卡住）
- 如果服务刚启就挂，但 status 显示 “active (running)”，大概率是 Restart 策略掩盖了失败
查是否被 OOM Killer 干掉，别只盯服务日志
OOM Killer 的动作不记在服务 unit 日志里，只留在内核缓冲区：
- 执行 dmesg -T | grep -i "killed process"，看到类似 Killed process 8921 (java) total-vm:3.2g, anon-rss:2.9g 就基本确认
- 检查该服务是否设了内存限制：systemctl show your-service.service | grep MemoryMax；没设的话，更容易被选中
- 查看对应 cgroup 的 OOM 控制状态：cat /sys/fs/cgroup/memory/system.slice/your-service.service/memory.oom_control，值为 0 表示已触发过 OOM
检查 Restart 策略和启动限频，防止“假正常”
Restart=always 或 on-failure 会让进程一挂就拉，掩盖原始问题：
- 运行 systemctl show your-service.service | grep -E "(Restart|StartLimit)"，看清是否启用了自动重启及频次限制
- StartLimitBurst 和 StartLimitIntervalSec 共同控制单位时间最多重启几次；超限后会进 failed 状态，这时才暴露真实错误
- 临时禁用自动重启以便观察：先 systemctl stop your-service.service，再 systemctl reset-failed your-service.service，最后 systemctl start your-service.service
顺藤摸瓜查依赖、配置与资源状态
服务本身没问题，不代表它能稳稳跑起来：
- 确认依赖服务是否就绪：systemctl list-dependencies --reverse your-service.service
- 验证配置文件语法是否正确，比如 nginx -t、redis-server --test-conf，错配常导致启动即退出
- 检查基础资源：用 free -h 和 df -h 看内存和磁盘是否吃紧；用 sensors 或 dmesg | grep -i thermal 排查过热
