Linux使用pgrep命令按名称查找进程PID的高效方法详解

排查线上问题时，最常遇到的需求是——"找到某个进程的PID"。很多人习惯用 ps aux | grep xxx，但这种方式有个让人头疼的问题：grep 自身也会出现在结果里。

$ ps aux | grep nginx
root      1234  0.1  0.3  54200  3120 ?        Ss   10:00   0:00 nginx: master process
www-data  1235  0.0  0.2  54600  2840 ?        S    10:00   0:00 nginx: worker process
user      5678  0.0  0.0  11268   960 pts/0    S+   10:05   0:00 grep --color=auto nginx

最后一行 grep nginx 就是噪音。虽然可以用 ps aux | grep nginx | grep -v grep 过滤，但写起来很啰嗦。而 pgrep 就是为解决这个问题而生的——它直接返回匹配的 PID，干净利落。

为什么需要 pgrep？

回到最根本的场景：你需要知道某个进程的 PID，然后做点什么——可能是查看资源占用，可能是发送信号，也可能是统计数量。用 ps aux | grep 这条组合命令，结果里总带着 grep 自己的进程，还得额外过滤一层。而 pgrep 专干这件事，输出就是纯 PID，一行一个，可以直接传给其他命令。

基本用法

# 查找 nginx 的所有 PID
$ pgrep nginx
1234
1235

输出简洁到极致，一个数字一行。这种设计天然适合脚本场景：

# 杀死所有 nginx 进程
$ pgrep nginx | xargs kill

# 查看某个进程的详细信息
$ ps -p $(pgrep -o nginx) -f

核心参数详解

-f：匹配完整命令行

默认情况下，pgrep 只匹配进程名的前 15 个字符（这是 Linux 内核的限制）。如果你的 Python 脚本名字很长，可能匹配不到：

# 默认只匹配进程名，可能匹配不到
$ pgrep my_long_python_script
# 没输出

# -f 匹配完整命令行
$ pgrep -f "my_long_python_script"
12345

这个参数在实际工作中用得最多，因为大多数时候我们想匹配的是命令行参数，而不是进程名本身：

# 查找所有运行 python app.py 的进程
$ pgrep -f "python app.py"
12345
12346

# 查找监听 8080 端口的 ja va 进程
$ pgrep -f "ja va.*8080"
56789

-u：按用户筛选

在多用户服务器上，这个参数非常实用：

# 查找 www-data 用户的所有进程
$ pgrep -u www-data
1234
1235
1236

# 组合使用：查找 root 用户的 nginx 进程
$ pgrep -u root nginx
1234

# 排除某个用户：查找非 root 的所有 node 进程
$ pgrep -u root -v node
23456
23457

-v 是反向匹配，类似 grep 的 -v，可以灵活地排除某些用户。

-l 和 -a：显示进程信息

默认只输出 PID，不太直观：

# -l 显示 PID 和进程名
$ pgrep -l nginx
1234 nginx
1235 nginx

# -a 显示 PID 和完整命令行
$ pgrep -a node
12345 node /app/server.js
12346 node /app/worker.js

调试时用 -a 特别方便，一眼就能看到每个进程在干什么，连启动参数都一目了然。

-n 和 -o：最新和最旧

当一个服务有多个进程时，你可能只想操作其中一个：

# 只获取最新的 node 进程（最后启动的）
$ pgrep -n node
12346

# 只获取最旧的 node 进程（最先启动的）
$ pgrep -o node
12345

这在重启服务时很有用——先杀掉旧进程，再启动新的：

# 重启 node 服务
$ kill $(pgrep -o node) && npm start

-c：统计匹配数量

有时候你不需要具体的 PID，只想知道有多少个进程在跑：

# nginx 跑了几个 worker？
$ pgrep -c nginx
3

# 某个用户跑了多少个 node 进程？
$ pgrep -u deploy -c node
5

-P：按父进程查找

查找某个进程的所有子进程：

# 找到 PID 为 1234 的所有子进程
$ pgrep -P 1234
1235
1236
1237

这在排查进程树时很有用，比如你想知道某个主进程下面挂了多少工作进程。

-x：精确匹配

默认是正则模糊匹配，pgrep ssh 会同时匹配 sshd 和 ssh-agent：

# 模糊匹配（默认）
$ pgrep ssh
1234    # sshd
1235    # ssh-agent

# 精确匹配
$ pgrep -x sshd
1234

-d：自定义分隔符

默认输出用换行分隔，但你可以改成逗号、空格等：

# 逗号分隔，方便传给其他命令
$ pgrep -d, nginx
1234,1235,1236

# 空格分隔
$ pgrep -d' ' nginx
1234 1235 1236

pgrep 与 pkill 的配合

pkill 是 pgrep 的"兄弟命令"，用法几乎一样，只不过它是直接发信号给匹配的进程：

# 优雅重启 nginx
$ pkill -HUP nginx

# 杀死所有 node 进程
$ pkill node

# 杀死某个用户的所有进程（慎用！）
$ pkill -u username

实际工作中，pgrep 先查、pkill 后杀，组合起来就是一套完整的进程管理流程。想确认再动手？先用 pgrep -a 看看匹配的是哪些进程，确认无误后再用 pkill 下手。

pgrep 底层原理

pgrep 的实现其实不算复杂。它直接读取 /proc 文件系统，遍历 /proc/[pid]/ 目录下的进程信息：

# pgrep 本质上就是在遍历这些目录
$ ls /proc | grep -E '^[0-9]+$'
1    10   123  124  ...

每个进程目录下有 comm（进程名）和 cmdline（完整命令行）等文件：

# 查看进程名
$ cat /proc/1234/comm
nginx

# 查看完整命令行
$ cat /proc/1234/cmdline | tr '' ' '
nginx: master process /usr/sbin/nginx -g daemon on;

pgrep 的 -f 参数就是去读 cmdline，默认模式则读 comm。这也是为什么 -f 会慢一点——读取和匹配的数据量更大。理解这个原理，你就知道什么时候该用 -f、什么时候默认模式就够了。

实战脚本示例

1. 检查服务是否运行

#!/bin/bash
# check_service.sh
SERVICE=$1

if pgrep -x "$SERVICE" > /dev/null; then
    echo "$SERVICE is running (PID: $(pgrep -o $SERVICE))"
else
    echo "$SERVICE is not running"
    exit 1
fi

2. 批量重启所有 node 进程

#!/bin/bash
# restart_all_node.sh
PIDS=$(pgrep -f "node.*app")

if [ -z "$PIDS" ]; then
    echo "No node app processes found"
    exit 0
fi

echo "Found node processes: $PIDS"
echo "$PIDS" | xargs kill
sleep 2
npm start
echo "Restarted"

3. 监控进程数量告警

#!/bin/bash
# monitor_workers.sh
MAX_WORKERS=10
COUNT=$(pgrep -c -f "python worker")

if [ "$COUNT" -gt "$MAX_WORKERS" ]; then
    echo "WARNING: Too many workers ($COUNT > $MAX_WORKERS)"
    # 发送告警
fi

小结

相比 ps aux | grep 的组合拳，pgrep 更简洁、更干净，也更适合在脚本中使用。几个最常用的场景：

• 快速查 PID：pgrep nginx
• 查看完整命令：pgrep -af node
• 统计进程数：pgrep -c -f "python worker"
• 按用户过滤：pgrep -u www-data -l