推荐使用pgrep判断进程是否存在，因其专为查进程设计，可精确匹配（-x）、按命令行匹配（-f），返回值0表示存在、非0表示不存在；若用ps|grep则须规避grep自身干扰和短名误匹配。
直接用 pgrep 或 ps 配合条件判断就能实现，关键不是“怎么写”，而是“怎么写得准、不误杀、不漏判”。下面分几个实用角度说清楚。
用 pgrep 判断进程是否存在（推荐）
pgrep 是专为查进程设计的命令，比 ps | grep 更干净、更可靠。
-
pgrep -x mysqld：精确匹配进程名（完全一致），避免匹配到mysqld_safe或日志里的字符串 -
pgrep -f "python.*server.py"：按完整命令行匹配，适合带参数启动的脚本 - 返回状态码是核心：
$? == 0表示找到进程，$? != 0表示没运行
用 ps + grep 的注意事项（慎用但常见）
如果必须用 ps | grep，务必避开两个经典坑：
- grep 自身会出现在结果里 → 必须加
grep -v grep - 进程名太短（如
java）容易误匹配 → 改用带路径或参数的特征串，例如grep "/opt/app/start.sh"或grep "MyAppMain" - 建议加上
-w（单词边界）：ps -ef | grep -w "nginx" | grep -v grep
重启逻辑要区分场景
不是所有“没进程”都该直接启动，得看上下文：
- 如果是守护进程（如 nginx、redis），直接
systemctl start xxx或/etc/init.d/xxx start - 如果是自定义脚本（如
python app.py），建议用nohup python /path/app.py &，并记录 PID 文件便于后续管理 - 若进程刚被 kill，可能残留端口或锁文件 → 启动前加清理步骤，比如
fuser -k 8080/tcp或rm -f /tmp/app.pid
放进循环或定时任务才真正生效
单次检查没意义，得持续监控：
- 后台常驻循环：
while sleep 10; do check_and_restart; done，适合关键服务 - 定时任务（crontab）：
*/2 * * * * /path/check.sh，每两分钟跑一次，更轻量、易管理 - 注意日志输出：重定向 stdout/stderr 到文件，比如
>/var/log/monitor.log 2>&1，方便排查失败原因
