最可靠方式是执行readlink -f /proc/PID/exe获取进程真实可执行文件绝对路径，因ps仅显示命令名、which/whereis依赖当前环境且不覆盖虚拟环境或自定义路径；辅以/proc/PID/cmdline和/proc/PID/cwd可完整还原运行上下文。

怎么拿到进程真正的可执行文件绝对路径

只靠 ps 输出的命令名（比如 python 或 node）根本不能确定它到底跑的是哪个二进制文件。系统里装了多个 Python、用了 pyenv 或 conda、或者进程是用绝对路径启动的，ps 都不显示真实路径。

唯一可靠的方式是读取 /proc//exe 这个符号链接：

• 先用 pgrep -f xxx 或 ps -ef | grep xxx 拿到 PID
• 执行 readlink -f /proc//exe，直接输出解析后的绝对路径
• 如果看到 (deleted) 后缀，说明文件已被删但进程还在跑——路径仍有效，只是磁盘上没了

为什么不能用 which 或 whereis 查进程路径

which python 返回的是当前 shell 的 $PATH 下第一个匹配项，跟正在运行的进程完全无关；whereis python 只扫系统包管理器安装路径（如 /usr/bin、/usr/local/bin），对用户自建路径（~/miniconda3/bin、~/.pyenv/versions/3.11.9/bin）或容器内路径无效。

常见失效场景：

• 进程由 systemd 启动，ExecStart=/opt/myapp/bin/start.sh，ps 显示 start.sh，which 根本查不到
• 脚本里用了 #!/usr/bin/env python3，实际运行的是虚拟环境里的 python，which 返回系统默认版本
• 进程在 Docker 容器里，宿主机的 which 完全不适用

工作目录和完整命令行怎么一起看

/proc//exe 只告诉你“程序本体在哪”，但启动行为还依赖工作目录和参数。这三个信息必须一起看才完整：

Obsidian (Linux)

操作 Obsidian 库（纯 Markdown 笔记），并通过 notesmd-cli 实现自动化。

下载

• 工作目录：readlink -f /proc//cwd（或用 pwdx ）
• 完整命令行：cat /proc//cmdline | tr '\0' ' '（注意参数间用 \0 分隔，不是空格）
• 环境变量：cat /proc//environ | tr '\0' '\n' | grep ^PATH=，能帮你理解为什么 exe 指向那个路径

例如一个 Python 进程的 exe 指向 ~/.pyenv/versions/3.11.9/bin/python，但 cwd 是 /home/user/project，cmdline 里带 --config config.yaml，三者合起来才是真实上下文。

权限和兼容性要注意什么

读取 /proc//exe 和 /proc//cwd 需要能访问目标进程的 /proc 子目录——通常要求你是进程所有者或 root。普通用户查自己启动的进程没问题，查别人（尤其是 root 进程）会 Permission denied。

另外：readlink -f 在旧版 BusyBox 或某些嵌入式系统里可能不支持 -f 选项，这时得用 ls -l /proc//exe 手动解析箭头后面的路径，再处理软链嵌套。

最常被忽略的一点：进程刚 fork 出来还没 exec 的瞬间，/proc//exe 会指向 /proc//exe (deleted) 或报错，这不是异常，而是生命周期状态——此时看 cmdline 和父进程更靠谱。