Linux服务频繁崩溃重启的根源在于自愈机制掩盖了真实故障，需通过journalctl查退出日志、dmesg确认OOM Killer、systemctl show分析Restart策略、list-dependencies验证依赖，并检查配置与资源瓶颈。
Linux服务频繁崩溃重启，不是随机事件，而是系统在尝试自愈时暴露的深层问题。关键不是“怎么让它多重启几次”，而是弄清它为什么每次都会退出——是代码缺陷、资源枯竭、依赖缺失，还是被内核强制终止。
先看退出瞬间发生了什么
systemctl status 只告诉你“现在活着”，但真正线索藏在退出那一刻的日志里：
- 运行 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'（启动卡住超时）
- 如果状态显示 “active (running)” 却实际不可用，大概率是 Restart 策略掩盖了刚启就挂的事实
确认是否被 OOM Killer 干掉
服务日志里不会写“我被杀死了”，这个动作只记在内核日志中：
- 执行 dmesg -T | grep -i "killed process"，看到类似 Killed process 1245 (python) total-vm:2.8g, anon-rss:2.5g 就基本坐实
- 检查该服务是否有内存限制：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 像创可贴，盖住了伤口，也耽误诊断：
- 运行 systemctl show your-service.service | grep -E "(Restart|StartLimit)"，看清是否启用自动重启、频次限制（如 StartLimitBurst=3 和 StartLimitIntervalSec=600）
- 超限后服务会进 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（过热）
