linux进程频繁重启是系统响应异常的明确信号，需按日志时间点→被谁杀→为何被杀→是否被自动拉起的顺序回溯，重点排查oom、磁盘满、硬件故障及systemd重启策略掩盖的真实失败。
Linux进程频繁重启，不是随机现象，而是系统在响应某种明确异常。关键在于别只盯着服务本身“为什么挂”，而要顺着线索一层层回溯：从日志时间点出发，看是被谁杀的、为什么被杀、是不是被自动拉起来掩盖了真实失败。
查日志：先锁住重启发生的时间和触发动作
重启前几乎总留有痕迹。用这几个命令快速定位关键窗口：
- who -b 或 last reboot -n 5 -F：一眼看出最近几次重启的具体时间，判断是否规律（如每小时整点）
-
journalctl -b -1 -p err | grep -i "shutting\|reboot\|panic\|oom"：查上一次启动中的错误，重点看 shutdown 前后三行（加
-B 3 -A 3） - dmesg -T | grep -E "kill|oom|error|thermal|fail"：内核级事件集中地，OOM Killer 日志、CPU 过热、磁盘报错全在这里
盯 systemd 重启策略：小心“假运行”掩盖真问题
很多服务 unit 文件里写了 Restart=always 或 on-failure，导致进程一退出就被立刻拉起，systemctl status 显示“active (running)”只是幻觉。
- 运行 systemctl show 服务名.service | grep -E "(Restart|StartLimit)"，确认是否启用了高频重启保护
- 临时禁用自动恢复：systemctl stop 服务名 && systemctl reset-failed 服务名 && systemctl start 服务名，然后观察首次启动是否直接失败
- 若启动即退出，journalctl -u 服务名 -n 50 --no-pager -o cat 看最干净的错误输出，常有“Address already in use”“Permission denied”或配置语法错误
验底层资源与硬件：服务没崩，但系统快撑不住了
进程被杀、服务反复启停，常是内存、磁盘或硬件异常的下游表现。
- OOM 杀手已出手？：运行 dmesg -T | grep "Killed process"，再结合 free -h 和 cat /proc/meminfo 看 available 是否长期低于 500MB
- 磁盘写满或只读？：df -h 查 /、/var、/tmp；mount | grep ro 看是否意外只读挂载
- CPU 过热或电源不稳？：sensors（需安装 lm-sensors），dmesg | grep -i "thermal\|power"
- 硬盘开始掉链子？：smartctl -a /dev/sda | grep -E "(Reallocated|Pending|Uncorrect)"，异常值升高说明硬件风险临近
梳定时任务与依赖链：重启可能根本不是服务自己的事
有些重启是脚本悄悄干的，有些失败是上游服务没起来导致的连锁反应。
- 检查所有可能触发重启的入口：crontab -l（当前用户）、ls /etc/cron.* /etc/cron.d/（系统级）、systemctl list-timers --all（systemd timer）
- 翻一翻 /etc/init.d/ 和 /etc/systemd/system/ 下有没有名字含
reboot、restart、watchdog的脚本 - 查依赖是否就绪：systemctl list-dependencies --reverse 服务名，再逐个 systemctl status 那些 failed 的上游单元
