Linux怎么查看具体的进程执行路径

/proc/PID/exe 往往是拿到进程路径时最直接、也最稳妥的来源。这个链接由内核负责维护，指向的是进程真正加载的可执行文件；即便文件后来被重命名、挪了位置，或者环境变量发生变化，它也不会因此失真。相比之下，ps、cmdline、which 这类方式都不能真正替代它。要把进程的运行上下文还原完整，还得结合 /proc/PID/cwd 和 /proc/PID/cmdline 一起看，这才够全面。

/proc//exe 是最直接、最可靠的路径来源，它指向进程实际加载的可执行文件。其他方法（如 ps、cmdline）只给命令名或启动参数，不能替代它。

为什么 /proc//exe 是首选

这个符号链接是由内核持续维护的。只要进程还活着，执行 readlink /proc//exe，拿到的就是当前真实可执行文件的绝对路径。哪怕文件后来被重命名、被挪了位置，只要中间没有被 execve() 替换掉，这个链接照样是有效的。也正因为如此，ps -f -p 里看到的 args 字段，很多时候未必能反映实际情况：表面上写着 /usr/bin/python，真正跑起来的可能却是 /opt/myapp/venv/bin/python；而 cmdline 里记录的，往往是脚本路径，并不是解释器本体。

• readlink -f /proc//exe 自动解析软链嵌套（比如指向 /usr/bin/ja va，而它又软链到 /etc/alternatives/ja va）
• 对僵尸进程无效（exe 不可用），但正常运行的进程基本都支持
• 需有读取权限：普通用户只能查自己启动的进程；查系统进程需 root 或 ptrace 权限

pwdx 和 /proc//cwd 查的是工作目录，不是执行路径

很多人误把 pwdx 或 readlink /proc//cwd 当作“执行路径”，其实它只是进程当前 chdir() 的位置，和可执行文件所在路径无关。比如一个在 /tmp 启动的 nginx，cwd 是 /tmp，但 exe 仍是 /usr/sbin/nginx。

• pwdx 更简洁，但输出格式固定（: ），不适合脚本解析
• readlink -f /proc//cwd 返回绝对路径，可用于调试配置文件加载逻辑（比如读取 ./config.yml 时实际找的是哪一版）
• 某些特权进程（如 init、容器 init 进程）的 cwd 可能不可读，返回 Permission denied

lsof -p 的 txt 类型文件不等于可执行路径

lsof -p 输出中带 txt 标记的行常被当作“执行文件”，但它只是当前映射为代码段的文件——可能是主二进制，也可能是动态库（如 libc.so.6），甚至是个被 mmap(PROT_EXEC) 加载的 JIT 编译块。

• 真正要找可执行文件，只认 COMMAND 列 + txt 行里 NAME 字段路径，且 FD 是 txt、TYPE 是 REG、SIZE/OFF 非零
• Ja va、Node.js 等运行时进程，txt 行大概率是 JVM 或 node 二进制，不是你写的 .jar 或 server.js——后者得看 cmdline
• lsof 需要 cap_sys_ptrace 或 root 权限，普通用户查不到其他用户的进程

别依赖 ps -o args 或 cmdline 推断执行路径

ps -p -o args 和 cat /proc//cmdline | tr '' ' ' 给出的是启动时传入的 argv[0] 和参数，不是可执行文件路径。argv[0] 可以被任意伪造，比如 execve("/tmp/malware", ["sshd", "-D"], ...)，ps 会显示 sshd -D，但真实路径是 /tmp/malware。

• Shell 脚本启动时，cmdline 显示的是解释器路径 + 脚本路径（如 /bin/bash /home/user/deploy.sh），这时 exe 是 /bin/bash，不是脚本本身
• 容器环境里，cmdline 常是 /bin/sh -c ...，真实业务程序得靠 exe 链接再层层追溯
• cmdline 对僵尸进程为空，ps 可能显示 [defunct]，此时只有 exe（如果还存在）能提供线索

/proc//exe 本身不包含启动参数或工作目录，它只是那个被 execve() 加载的文件。真要还原完整上下文，得组合 exe、cwd、cmdline 三者——少一个，就可能把 /usr/local/bin/python 和 /opt/app/main.py 的关系搞错。