ps -ef | grep nginx 是查看 nginx 是否启动的最常用命令，可显示主进程与工作进程；为避免匹配到 grep 自身，建议用 ps -ef | grep '[n]ginx'；需结合 ps -eo pid,args 确保获取完整启动参数。
ps 的 -f 或 -eo 配合 args 字段，而不是默认的 ps aux —— 后者会截断长命令，根本看不到完整参数。
ps -ef 能看到完整启动参数，但要注意字段顺序和截断风险
ps -ef 是最常用也最稳妥的起点，它用 SysV 风格输出，CMD 列默认显示完整命令行（包括所有参数），只要终端宽度够、没被 shell 自动换行干扰。
- 字段顺序固定：
UID、PID、PPID、C、STIME、TTY、TIME、CMD - 如果某条命令特别长（比如含大量环境变量或路径），
ps可能仍会截断 —— 这时不能靠加宽终端，而要改用-eo指定输出 -
ps -ef | grep nginx会匹配到 grep 自身那行，建议用ps -ef | grep '[n]ginx'规避
ps -eo pid,cmd --sort=-pid 精准控制输出列，避免截断
想确保看到每个进程的完整启动命令，必须显式指定 cmd 或 args 字段，并禁用默认宽度限制：
-
ps -eo pid,cmd：只输出 PID 和完整命令行，无列宽限制，适合管道处理 -
ps -eo pid,args效果等同于cmd，但语义更明确（args强调参数部分） - 加
--sort=-pid可按 PID 降序排列，方便定位新启动的进程 - 注意：
ps -eo pid,comm只显示二进制名（如java），不带参数，别混淆
遇到 systemd 服务时，ps 看不到原始参数？用 systemctl show
systemd 管理的服务（比如 docker.service）在 ps 中常显示为 /usr/bin/dockerd，但实际启动参数由 unit 文件定义，ps 不会还原。
- 查真实启动参数：运行
systemctl show --property=ExecStart docker.service - 查完整环境与参数：用
systemctl cat docker.service看 unit 文件内容 - 如果服务已启动但参数被覆盖（如通过
systemctl set-environment），需结合systemctl show --property=Environment -
ps显示的是进程当前实际执行的命令，不是 systemd 解析后的最终结果 —— 二者可能不一致
procfs 是终极来源，但别直接 cat /proc/*/cmdline
每个进程的完整命令行参数真实存于 /proc/<pid>/cmdline</pid>，以 null 字节分隔，可读但不可直接 cat —— 会乱码或卡住终端。
- 安全读取方式：
tr '\0' ' ' - 批量查看所有进程参数：
for pid in /proc/[0-9]*; do echo "$(basename $pid): $(tr '\0' ' ' /dev/null)"; done | head -20 - 注意：
/proc/<pid>/cmdline</pid>可能为空（如内核线程）或权限不足（非 root 查不到其他用户进程） - 这是最权威的来源，但日常排查优先用
ps -eo pid,args，它底层就读这个文件，只是做了格式化
args 是镜像定义的，还是 docker run 时覆盖的；又比如 Java 进程的 -D 参数是否在启动后被 JMX 动态修改。这时候光看 ps 输出不够，得结合 /proc/<pid>/environ</pid> 和应用自身的状态接口。
