监控linux服务器进程什么时候结束，linux查看进程运行多长时间？

要监控Linux服务器进程什么时候结束，最可靠的办法不是实时监听，而是通过轮询进程状态或等待子进程退出信号。 下面按从简单到复杂的顺序，给出可落地的操作方案和命令，覆盖手动排查、脚本监控和系统级守护三种场景。

linux查看进程结束时间的常见思路

进程结束不是一个“事件广播”，内核只通知父进程收到SIGCHLD信号，如果你不写C代码,就要通过间接手段判断消失时刻。

进程生命周期与退出状态

一个进程从创建到结束，会经历运行、睡眠、停止、僵尸等状态，当进程退出后，它的PID可能被复用，所以不能只凭PID不存在就断定结束时间，应该结合进程名、启动时间、父进程ID一起判断。

退出码能告诉我们什么

每个进程结束时会返回一个退出码，0表示正常结束，非0表示异常，在脚本里可以用捕获前一个命令的退出状态，但退出码本身不包含“什么时候结束”的信息,你需要在捕获它的那一刻记录当前时间。

linux查看进程结束时间的三种常用方法

使用ps轮询捕获进程消失的时间戳

最直观的办法是写一个循环，每隔几秒检查目标进程是否存在，以下命令每秒检查一次名为nginx的进程,进程消失后立即打印时间：

while ps -ef | grep -v grep | grep nginx > /dev/null; do
    sleep 1
done
echo "nginx进程结束时间: $(date '+%Y-%m-%d %H:%M:%S')"

这个方法的缺点是不精确，最长可能有1秒的误差，追求秒级精确时，可以把sleep换成1，但会消耗更多CPU。轮询间隔越短，记录的时间越接近真实退出时刻。

利用/proc文件系统追踪进程状态

Linux内核会把每个进程的信息挂在/proc/<PID>目录下，只要这个目录存在，进程就还活着,下面是监控PID为1234的进程退出时间的脚本：

PID=1234
while [ -d /proc/$PID ]; do
    sleep 0.2
done
echo "PID $PID 已结束，时间: $(stat -c %y /proc/$PID 2>/dev/null | tail -1)"

注意

/proc/$PID目录下的stat文件记录了进程启动时间，但没有直接记录结束时间，要精确记录结束瞬间，必须在进程消失后立刻执行date命令。

借助wait命令等待前台子进程

如果你的服务器是通过Shell启动的进程，直接用wait最省事。wait会阻塞当前Shell，直到指定PID结束,然后立即执行后续命令：

./long_running_task &
TASK_PID=$!
wait $TASK_PID
echo "进程 $TASK_PID 结束，退出码: $?"

这个方式没有轮询延迟，因为内核会在子进程退出时唤醒wait,适合在脚本内部监控自己启动的进程。

shell脚本监控进程退出的实用做法

很多运维场景是：进程崩溃了，你需要知道它几点几分挂的，最好还能自动拉起来,下面给出两个可以实际用的脚本模板。

写一个循环检测进程是否还在

比如监控Java服务/opt/app/start.jar，脚本每3秒检查一次，一旦进程消失，就写一条带时间的记录到/var/log/monitor.log：

#!/bin/bash
PROCESS_NAME="StartApplication"
LOG_FILE="/var/log/monitor.log"
while true; do
    PID=$(pgrep -f "$PROCESS_NAME" | head -1)
    if [ -z "$PID" ]; then
        echo "$(date '+%Y-%m-%d %H:%M:%S') - 进程 $PROCESS_NAME 已结束" >> $LOG_FILE
        # 在这里可以追加重启命令
        # nohup java -jar /opt/app/start.jar > /dev/null 2>&1 &
        exit 0
    fi
    sleep 3
done

用pgrep -f匹配完整命令行的好处是准确，不容易误杀同名进程，但注意这条命令只能检测一次，如果要持续守护，需要外层再套一个while循环。

利用tail –pid跟踪日志文件判断退出

Linux的tail命令自带--pid参数，当指定PID消失时，tail会自动退出，利用这个特性,可以边看日志边等进程结束：

PID=1234
tail -f --pid=$PID /var/log/myapp.log
echo "进程 $PID 结束了，日志已跟踪到最后一行"

这个命令在进程结束的同时会停止跟随，你可以在后续命令里记录时间，适合现场排查,适合的服务器场景是不想额外安装工具的情况下快速定位。

记录退出时刻并写入系统日志

把监控结果交给logger命令，就能让退出时间进入/var/log/messages或journalctl：

echo "myapp ended at $(date +%F_%T)" | logger -t process_monitor

之后用journalctl -t process_monitor查看,就可以把所有被监控进程的结束时间汇总在一起。

systemd服务与第三方工具如何监控进程结束

如果你的Linux服务器使用systemd，很多监控工作可以交给系统本身,不需要写脚本。

systemd的ExecStop和ExecStopPost

在service文件中加入ExecStopPost,进程退出后会自动执行一条命令：

[Service]
ExecStart=/usr/bin/python3 /opt/app/server.py
ExecStopPost=/bin/sh -c 'echo "server stopped at $(date)" >> /var/log/stop.log'

ExecStopPost在服务停止后无论正常退出还是崩溃都会执行，是记录结束时间最可靠的systemd原生方案，修改后执行systemctl daemon-reload并重启服务。

使用supervisor或monit守护进程

行业共识认为，对于需要长时间稳定运行的服务，单独写轮询脚本不如用专门的守护工具，supervisor可以管理进程，并在进程意外退出时自动重启，同时提供stdout_logfile和事件监听器，monit则更偏向于监控资源占用和进程状态,检测到进程消失时执行自定义脚本。

工具配置虽然要花一点时间学习，但好处是监控、告警、重启一体化,适合生产环境的服务器进程管理。

监控进程结束后要做什么：告警与重启

记录结束时间只是第一步，更重要的是一旦发现进程结束,立刻执行后续动作。

在脚本中集成钉钉或邮件通知

用curl发送通知到钉钉机器人的方法：

curl -s -X POST "https://oapi.dingtalk.com/robot/send?access_token=你的token" 
    -H "Content-Type: application/json" 
    -d "{"msgtype": "text", "text": {"content": "进程异常退出，时间: $(date)"}}"

邮件通知可以用mailx,发送前确认服务器已经安装并配置好SMTP。

自动重启的边界

建议只在确认进程没有不可恢复的故障时自动重启，重试超过3次后停止，避免陷入频繁重启的循环,可以在重启脚本里设置一个计数器：

RETRY_COUNT=$((RETRY_COUNT+1))
if [ $RETRY_COUNT -le 3 ]; then
    nohup /opt/app/start.sh > /dev/null 2>&1 &
else
    echo "重试超过3次，停止自动重启" | logger -t process_monitor
fi

监控linux服务器进程什么时候结束：常见问题解答

进程消失后PID立刻被复用，怎么避免误判？

判断进程是否结束不能只看PID是否存在，还要核对进程启动时间，用ps -o lstart -p PID查看启动时间，如果启动时间比你监控的进程晚，说明这是一个新的进程占用了原PID，更稳妥的方式是把进程启动时的时间戳记录下来,监控脚本里同时比对启动时间。

用ps轮询监控会漏掉非常短的进程吗？

会，如果进程生命周期短于轮询间隔，你根本发现不了它曾经存在，要捕获这类短进程需要改用auditd审计系统或ebpf工具，才能在进程创建的瞬间留下记录，对于只想知道“某个常驻进程什么时候结束”的场景,轮询足够了。

systemd的ExecStopPost在进程被kill -9时能执行吗？

可以。ExecStopPost由systemd进程触发，不是由被监控进程执行，所以即使进程收到SIGKILL，只要systemd还在，它就会执行，但如果内核崩溃、服务器断电，那么没有任何用户态工具能够记录结束时间,只能依赖带外管理或服务器硬件监控。

回到最初的问题：监控Linux服务器进程什么时候结束，没有银弹。 前台脚本用wait，后台守护用systemd，临时排查用/proc轮询，选哪种取决于你的场景和能接受的误差范围，只要把监控脚本跑起来,精确到秒的结束时间随手可得。