先看活了多久，再谈为什么挂
服务“又挂了”时，第一件事不是重启，而是确认它到底活了多久：ps 的 lstart 给出启动时刻、etimes 给出已运行秒数。etimes 只有几十秒，说明刚被拉起甚至正在循环重启，此时重启只会掩盖原因。之后按顺序取证据：应用日志、服务管理器（systemd）的 unit 日志、内核 dmesg 里的 OOM 记录与端口占用情况。
基本信息
| 适用平台 | Linux（procps-ng 的 ps、journalctl、dmesg） |
|---|---|
| 关键字段 | lstart 启动时间、etimes 运行秒数、stat 进程状态 |
| 取证顺序 | 存活时间 → 应用日志 → 服务管理器日志 → 内核 OOM / 端口冲突 |
| 相关命令 | ps -eo、journalctl -u、dmesg -T、ss -tlnp、uptime -s |
| 托管方式差异 | systemd 看 NRestarts；其他守护进程看各自的日志 |
典型使用场景
- 服务反复重启，判断是否被守护机制不断拉起
- 确认进程是否在故障时间点之后重启过
- 怀疑 OOM 杀进程，需要内核侧证据
- 端口冲突导致启动失败
- 恢复过程需要完整时间线用于复盘
存活时间与退出线索
存活时间与退出线索
ps -eo pid,lstart,etimes,cmd | grep -i 'app-server' | grep -v grep
# etimes 只有几十秒 → 刚重启过；lstart 给出准确启动时刻
journalctl -u app-server --since '10 min ago' --no-pager | tail -50
tail -n 100 /var/log/app/error.log
dmesg -T | grep -iE 'oom|killed process' | tail # -T 打印可读时间，便于对齐时间线
ss -tlnp | grep ':8080' # 端口被占是起不来的常见原因
systemctl show app-server -p NRestarts # systemd 托管的 unit 看重启计数
uptime -s # 系统启动时间，区分整机重启与进程重启线索与判断
| 线索 | 怎么看 | 指向的问题 |
|---|---|---|
| etimes 很小 | 进程刚启动 | 正在循环重启或刚被拉起 |
| lstart 与故障时间接近 | 崩在故障点附近 | 结合日志看崩溃前最后一条输出 |
| dmesg 出现 killed process | 内核 OOM 记录 | 内存不足被杀，要查内存峰值与限制 |
| ss 显示端口已被占 | 启动即失败 | 前一实例未退干净或端口被别的服务占用 |
| NRestarts 持续增长 | 守护不断拉起 | 先停掉自动重启再排查，避免日志被刷掉 |
| uptime -s 与 lstart 一致 | 整机重启过 | 检查电源、内核 panic 或云主机事件 |
把恢复过程记成时间线（几点退出、几点被拉起、错误码是什么）：排查循环重启时，时间线比单条日志有用得多。
systemd 的 Restart=always 会不断拉起崩溃进程：连续重启会刷掉日志、加剧资源竞争，必要时先 systemctl stop 再排查。