发布于2026-07-08 阅读(0)
扫一扫,手机访问
先说几个核心判断:查进程启动时间跟运行时长,Linux里其实有非常明确的指导原则。很多人在这上面栽过跟头,要么用了错误的字段,要么对输出结果理解有误。今天就把这件事彻底讲清楚。
ps -o lstart= -p PID 是最准、最省事的启动时间获取方式;需要运行时长就用 etime,别碰 time 或 STIME——它们根本不是一回事。
lstartlstart 输出完整时间戳,比如 Wed Jul 01 14:22:05 2026,带年份、星期、秒级精度,一眼就能判断是否跨月跨年。它不依赖 locale,英文系统下格式稳定,脚本解析也安全。
ps -o lstart= -p 1234(注意 = 后不加空格,否则会多出表头)ps -eo pid,lstart,comm --sort=-lstart | head -5ps -eo pid,lstart,cmd | grep nginx,但更干净的做法是 ps -C nginx -o pid,lstart,cmdsudoAlpine、BusyBox 或旧容器中的 ps 不支持 lstart,会报 unknown sort key: lstart,此时必须采用 fallback 方案etime,别被 TIME+ 或 time 带偏etime 是进程自启动以来经过的整秒数(向下取整),含休眠时间,数值稳定、可脚本化。而 time 字段(ps aux 第10列)是 CPU 实际占用时间,单位是 1/100 秒,值通常远小于真实存活时间。
ps -o etime= -p 1234 | xargs(xargs 去首尾空格,防空格干扰)date -d "@$(($(date +%s) - $(ps -o etime= -p 1234 | xargs)))" "+%Y-%m-%d %H:%M:%S"etime 可能从容器启动起算,而非进程 exec 时间etime 为负说明内核时间异常或进程刚 fork 尚未 exec,应跳过该结果STIME 列,但得人工推断ps -ef 的 STIME 列在 CentOS 6 或嵌入式系统中仍可用,但它格式模糊:显示 Jul01 表示本月 1 日,2025 表示去年,10:23 表示今天 10:23。无法自动化,仅适合人工排查。
date 确认当前年月日ps -eo pid,user,tty,stime,cmd | grep postgres 缩小范围STIME 显示 Jan01 而当前是 7 月,大概率是 2026-01-01;若显示 2024,而系统是 2026 年,则已运行两年多stime(ps aux 第10列)可能输出“5月21日”,脚本解析极易崩,不如直接绕开/proc/PID/stat 第22字段这是内核级记录,第22字段是进程启动时刻距系统 boot time 的 jiffies 数(非秒),结合 /proc/stat 中的 btime 和 CLK_TCK 才能换算出绝对时间。精度最高,但写成一行易出错,且多数场景没必要。
awk '{print $22}' /proc/1234/statgetconf CLK_TCK(绝大多数系统返回 100)grep btime /proc/stat | awk '{print $2}'$(btime) + $(starttime) / $(CLK_TCK),再传给 date -d @...lstart 或 etime 更稳
lstart 和 etime 是两个不同维度的字段——一个回答“什么时候启的”,一个回答“跑了多久”。很多人混淆它们,或试图用 time、STIME 替代,结果查到的时间要么错年份,要么差几个数量级。真正要落地用,就得盯住这两个字段,其他全是干扰项。
下一篇:统信UOS怎么安装网易云音乐
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
正版软件
正版软件
正版软件
正版软件
正版软件
1
2
3
4
5
6
7
8
9