排查 systemd 服务异常需先运行 systemctl status 查 Active 状态及退出码/信号，再用 journalctl -u -n 50 -o cat 查日志；注意 Restart= 策略掩盖错误、OOM Killer 静默杀进程（dmesg 验证）、守护进程退出码与信号捕获、fd/权限/工作目录限制，以及多条件叠加导致的循环失败。
查 systemd 服务状态和最近日志
绝大多数现代 Linux 发行版用 systemd 管理守护进程，异常退出后第一反应不是翻应用日志，而是看 systemd 是否记录了启动失败、被杀或崩溃信号。
- 运行
systemctl status <em>your-service-name</em>，重点看Active:行是否为failed，以及末尾几行的Process exited with code或Killed by signal - 用
journalctl -u <em>your-service-name</em> -n 50 --no-pager查最近 50 行日志；若服务已退出，加-o cat避免转义控制字符，更易读 - 注意
systemd的Restart=策略（如on-failure）可能导致频繁重启，掩盖原始错误——此时journalctl会显示多段“Started → Stopped”循环
确认进程是否被 OOM Killer 杀掉
内存耗尽时，内核会静默杀死占用最多内存的进程，不经过 systemd 正常终止流程，只在 dmesg 留下痕迹。
- 执行
dmesg -T | grep -i "killed process"，若输出类似[Wed Jan 10 14:22:33 2024] Killed process 12345 (mydaemon) total-vm:2456784kB, anon-rss:1890123kB，基本可定性为 OOM - 检查
/proc/<em>PID</em>/status中的OOMScoreAdj值（越正越容易被杀），以及容器环境是否设置了memory.limit_in_bytes - 临时验证：用
echo -17 > /proc/<em>PID</em>/oom_score_adj降低该进程被杀优先级（仅调试用，勿写入生产配置）
检查守护进程自身退出码和信号捕获
很多守护进程在初始化失败（如端口被占、配置文件语法错）时直接调用 exit(1) 或触发 SIGSEGV，但没打印足够上下文。
- 在服务 unit 文件中临时添加
Environment=LD_DEBUG=files,libs和StandardOutput=journal+console，让动态链接和标准输出强制进 journal - 若怀疑是信号导致退出，用
strace -f -p <em>PID</em> 2>&1 | grep -E "(exit|kill|sig)"实时抓取（需在进程启动后立刻 attach） - 检查代码中是否忽略
SIGPIPE（常见于日志写入断开时）或未处理SIGHUP（某些 systemd 版本在 reload 时会发）
验证文件描述符、权限与工作目录限制
守护进程 fork 后常切换用户、chdir 到 /、关闭所有 fd，这些操作若失败，会导致静默退出且无有效日志。
- 用
systemctl show <em>your-service-name</em> | grep -E "(LimitNOFILE|WorkingDirectory|User|NoNewPrivileges)"核对关键限制项 - 若服务以非 root 用户运行，检查其能否访问配置文件（
stat -c "%U:%G %a %n" /path/to/conf）、证书路径、socket 文件父目录等 -
LimitNOFILE过低（如默认 1024）可能使高并发服务在 accept 新连接时open()失败并退出——改LimitNOFILE=65536并重载 unit
真正难定位的往往是多个条件叠加：比如 OOM Killer 杀进程后，systemd 因 RestartSec=100ms 快速重启，新进程又因残留锁文件或端口未释放而立即失败，形成“启动→退出→重启”死循环。这时候得关掉自动重启，手动跑一次带完整 strace 和环境变量的命令，才能看到第一手失败原因。
