唯一可靠方式是先用pgrep等获取PID,再执行readlink -f /proc/PID/exe;ps、which、whereis均不可靠,因进程名不反映真实路径,且环境隔离场景下极易出错。

直接通过进程名查不到绝对路径,必须先拿到 PID,再读取 /proc/PID/exe。因为进程名(比如 python 或 node)只是命令名,不包含实际执行文件的位置;系统里可能同时存在多个同名可执行文件(如 pyenv、conda、手动编译版本),仅靠名字无法区分。
第一步:用进程名查出 PID
常用命令有三种,按推荐顺序:
-
pgrep -f "关键字"—— 最实用,支持模糊匹配完整命令行,例如pgrep -f myapp.py可匹配/home/u/app/venv/bin/python myapp.py -
pidof 进程名—— 适合精确匹配二进制名,如pidof nginx,但对脚本启动的进程(如用bash start.sh启动的服务)可能返回空 -
ps -ef | grep "关键字"—— 兼容性最好,但要注意过滤掉grep自身进程,建议加空格或用正则,例如ps -ef | grep "[m]yapp.py"
第二步:用 PID 获取真实可执行路径
这是唯一可靠的方式,核心是读取 /proc/PID/exe 这个符号链接:
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq(Cortex‑A9/A53 + FPGA)Linux 环境,调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查,支持 PetaLinux 开发。
-
readlink -f /proc/<strong>PID</strong>/exe—— 一行输出解析后的绝对路径,最简洁,推荐首选 -
ls -l /proc/<strong>PID</strong>/exe—— 显示软链接指向,末尾带(deleted)表示文件已被删但进程仍在运行 - 如果看到路径指向
/bin/bash或/usr/bin/python3,说明是脚本启动,需进一步看命令行:cat /proc/<strong>PID</strong>/cmdline | tr '\0' '\n'
第三步:补充上下文信息(按需)
单看可执行路径有时不够,比如想确认脚本是在哪启动的、用了什么参数:
-
pwdx <strong>PID</strong>—— 查进程当前工作目录(即启动时所在的目录,不是程序文件所在目录) -
cat /proc/<strong>PID</strong>/cmdline | tr '\0' '\n'—— 查原始启动命令,含全部参数,对调试启动异常特别有用 -
ls -l /proc/<strong>PID</strong>/fd/—— 查进程打开的文件描述符,可辅助判断配置文件、日志文件等加载位置
不需要依赖 which 或 whereis,它们查的是当前 shell 环境下的路径,跟正在运行的进程无关;容器内或使用 pyenv/conda 的场景下尤其不可靠。

















