服务进程突然消失应先查 systemd 日志：用 journalctl -u .service -n 100 --no-pager 查近期日志，加 -o cat 去噪；识别段错误（SEGV）、OOM Killer（status=137）、超时（timeout）等关键线索；再通过 dmesg、OOM 相关文件、Restart 策略、依赖服务及资源状态逐层排查根本原因。
服务进程突然消失，先查 systemd 日志
systemd 是现代 Linux 发行版的默认 init 系统，服务异常退出后，systemctl status 只显示当前状态，真正线索藏在 journal 中。journalctl -u <service-name>.service -n 100 --no-pager</service-name> 能快速拉出最近 100 行日志；若服务已崩溃，加 -o cat 去掉时间戳和优先级前缀，让错误更醒目。
常见干扰项：日志里出现 main process exited, code=killed, signal=SEGV 表示被段错误终止；code=exited, status=137 往往是 OOM Killer 杀掉的（注意不是服务自己退出）；Failed with result 'timeout' 则说明启动超时，可能卡在初始化阶段。
确认是否被 OOM Killer 终止
OOM Killer 在内存不足时会按 oom_score_adj 选中进程 kill，不写日志到服务 unit 日志里，只记在内核环缓冲区。运行 dmesg -T | grep -i "killed process"，如果看到类似 Killed process 12345 (python3) total-vm:2.1g, anon-rss:1.8g, file-rss:0k，基本就是它干的。
验证方式：
- 检查
/proc/<pid>/oom_score_adj</pid>（若进程还在）或历史systemctl show --property=OOMScoreAdjust - 看
systemctl show <service-name>.service | grep MemoryLimit</service-name>，没设MemoryMax的服务更容易被盯上 -
cat /sys/fs/cgroup/memory/system.slice/<service-name>.service/memory.oom_control</service-name>如果存在且值为0，说明该 cgroup 曾触发 OOM
检查服务配置中的 Restart 策略是否掩盖问题
很多服务 unit 文件里写了 Restart=always 或 Restart=on-failure，导致进程“刚挂就拉”，掩盖了真实失败原因。这种情况下，systemctl status 显示 “active (running)” 是假象——它只是刚被拉起来而已。
排查要点：
- 运行
systemctl show <service-name>.service | grep -E "(Restart|StartLimit)"</service-name>查重启策略和限制 -
StartLimitIntervalSec和StartLimitBurst控制单位时间内最多重启几次；超过后会进failed状态并锁住，这时才容易暴露原始错误 - 临时禁用自动重启：
systemctl stop <service-name>.service && systemctl reset-failed <service-name>.service && systemctl start <service-name>.service</service-name></service-name></service-name>，观察首次启动是否失败
依赖服务或资源不可用导致连锁失败
服务本身代码没问题，但依赖的数据库连不上、配置文件被删、socket 文件被清空、SELinux 拒绝访问，都会引发看似“无征兆”的重启。比如 PostgreSQL 服务启不来，依赖它的应用反复尝试连接失败，最终因健康检查超时被 systemd 杀掉再拉起。
关键动作：
- 用
systemctl list-dependencies --reverse <service-name>.service</service-name>看谁依赖它，再用--after/--before查启动顺序 - 检查
systemctl is-active和is-enabled对所有Wants=和Requires=列出的服务 - 对网络依赖，用
ss -tulpn | grep :<port></port>确认端口是否真被监听；对文件依赖，用strace -e trace=openat,open,connect -p <pid> 2>&1 | grep -E "(ENOENT|ECONNREFUSED)"</pid>抓实时系统调用错误
真正棘手的往往是那些没有显式报错、但卡在某一步等超时的场景——比如 DNS 解析失败导致服务初始化阻塞 90 秒，systemd 启动 timeout 默认 90 秒，刚好踩线失败。这类问题不会直接告诉你“DNS 不通”，得从超时点反推。
