Linux怎么查看具体的进程执行路径详细信息

更稳妥的做法，是直接执行readlink -f /proc//exe来拿到进程的绝对路径。原因不难理解：ps通常只会显示命令名，which和whereis又依赖当前环境，遇到虚拟环境或者自定义路径时，往往就不够用了。再结合/proc//cmdline和/proc//cwd一起看，整个运行上下文基本就能还原完整。

怎么直接拿到进程的绝对可执行路径

要想拿到最靠谱的结果，直接读 /proc//exe 才是正解，不要靠 ps 或 which 去“猜”。道理很简单：ps 通常只会给出命令名，比如 python，但它背后实际跑起来的，很可能是 /home/user/.pyenv/versions/3.11.9/bin/python；至于 which python，查到的是当前 shell 的 $PATH 解析结果，和那个进程本身其实不是一回事。

• 先用 pgrep -f your_keyword 或 ps -ef | grep your_keyword 拿到 PID
• 再运行 readlink -f /proc//exe —— 一行命令直接输出解析后的绝对路径
• 如果看到输出末尾带 (deleted)，说明二进制文件已被删，但进程还在跑，路径仍有效
• ls -l /proc//exe 也能看，但要自己解析箭头右边的内容，不如 readlink -f 直接

为什么只看 exe 不够，还得查 cmdline 和 cwd

知道程序本体在哪，不等于知道它在跑什么、从哪启动、依赖哪些配置。这三个字段必须一起看：

• cat /proc//cmdline | tr '' ' '：还原完整启动命令，比如 /usr/bin/node /var/www/app/server.js --port=3000
• readlink -f /proc//cwd：确认当前工作目录，影响相对路径加载（如 config.json 是否能被找到）
• pwdx 是个快捷替代，但不支持僵尸进程，且某些内核版本对特权进程返回空
• 注意：/proc//cmdline 对僵尸进程为空；/proc//cwd 对 init 或容器 init 进程可能不可读

用 fuser -v 快速反查路径归属哪个进程

当你只知道一个路径（比如 /var/log/nginx/access.log）被谁占着，想反推是哪个进程在写，fuser -v 比先找 PID 再查 /proc 更快：

• 普通用户运行 fuser -v /path 只能看到自己的进程；必须加 sudo fuser -v /path 才能看见系统级进程（如 rsyslog、nginx）
• ACCESS 列里的 txt 表示该进程正以可执行方式运行这个文件；cwd 表示这是它的当前工作目录；mem 表示 mmap 了该文件
• 查挂载点（如 /mnt/data）时，建议加 -m 参数：sudo fuser -v -m /mnt/data，避免漏掉子目录下的访问进程
• 如果输出里出现 kernel 作为 PID，说明是内核级操作（如 ext4 journal 写入），不能 kill，得从上层服务入手

别踩这些坑：常见误判和权限陷阱

很多“查不到路径”的问题，其实不是命令不会用，而是权限或场景理解错了：

• lsof -p 能列打开的文件，但它不保证显示 exe 路径——尤其对 setuid 进程或容器内进程，lsof 可能权限不足或信息受限
• ps -f -p 显示的 CMD 字段会被截断，且不包含绝对路径；ps e -p 虽能看环境变量，但 PWD 不一定等于 cwd
• 容器内进程的 /proc//exe 指向的是容器镜像里的路径（如 /usr/local/bin/python），宿主机上不存在对应文件，别拿宿主机的 which 去比对
• hidepid=2（常见于某些安全加固系统）会让非 root 用户看不到其他用户的 /proc/ 目录，此时 readlink 会报 No such file or directory，不是路径错，是权限挡住了

真正要确认一个进程“到底跑的是什么”，readlink -f /proc//exe + cat /proc//cmdline + readlink -f /proc//cwd 这三行命令缺一不可。任何只依赖单一工具或只查某一层信息的做法，都容易在多 Python 版本、虚拟环境、容器或 systemd 服务场景下翻车。