通过Crontab运行的Bash脚本执行pm2 restart all后进程持续重启求助

嘿，我之前也踩过类似的坑，咱们一步步拆解问题、搞定它：

先找准无限重启的核心诱因 #

最常见的触发点其实是Crontab的环境变量和你登录Shell的环境不匹配：

• PM2通常安装在用户的局部路径（比如$HOME/.npm），但Crontab默认的PATH非常有限，大概率找不到pm2命令，导致脚本执行时要么报错，要么拿不到正确的进程内存数据，误判为内存超标，反复触发重启。
• 另外，如果脚本里直接用pm2 list这类命令，Crontab运行时可能没加载用户的PM2配置（比如PM2_HOME环境变量），导致识别不到当前运行的PM2进程，进而每次都执行pm2 restart all。

针对性的解决方案 #

1. 给脚本补全环境变量 #

在监控脚本开头，先加载用户的环境变量，或者直接指定PM2的绝对路径：

# 加载当前用户的环境变量（替换成你的用户路径，比如/home/vaibhav/.profile）
source /home/vaibhav/.profile
# 或者先通过`which pm2`找到绝对路径，直接赋值
PM2_PATH=$(which pm2)

这样Crontab运行脚本时，就能正确找到PM2命令和对应的进程信息了。

2. 优化内存判断逻辑，避免误触发 #

原来的脚本可能只是简单判断内存是否超2G，但重启后的进程刚启动时内存很低，要避免短时间内脚本再次执行时误判（比如Crontab每分钟运行一次，重启后还没稳定就又被检查）。可以加精准筛选和日志记录：

# 用JSON格式解析PM2进程，筛选内存超过2048MB（2GB）的进程名称
pm2 list --format json | jq '.[] | select(.monit.memory > 2048) | .name' > /tmp/over_memory_processes.txt

# 只有当确实有超标进程时才执行重启，避免空触发
if [ -s /tmp/over_memory_processes.txt ]; then
    # 优先只重启超标进程，而非全部，减少不必要的影响
    $PM2_PATH restart $(cat /tmp/over_memory_processes.txt)
    echo "$(date): 检测到内存超标，重启进程: $(cat /tmp/over_memory_processes.txt)" >> /var/log/pm2_monitor.log
else
    echo "$(date): 所有PM2进程内存使用正常" >> /var/log/pm2_monitor.log
fi

这里用jq解析PM2的JSON输出，精准定位需要重启的进程，比直接restart all更稳妥，也方便通过日志排查问题。

3. 给Crontab任务配置必要环境变量 #

在你的Crontab任务里，直接指定PM2相关的环境变量，比如：

# 每分钟运行一次监控脚本，同时指定PM2_HOME和完整PATH
* * * * * PM2_HOME=/home/vaibhav/.pm2 PATH=/usr/local/bin:/home/vaibhav/.npm-global/bin:$PATH /home/vaibhav/scripts/pm2_memory_monitor.sh

这样Crontab运行时就有了正确的环境，能正常和PM2交互。

4. 排查脚本的单位判断错误 #

确认你原来的内存判断是否搞混了单位：PM2默认输出的内存是MB还是KB？比如pm2 monit显示的是MB，但如果脚本里把KB当成了MB，就会误以为内存一直超标，反复重启。可以用pm2 list --format json查看内存字段的数值，确保判断条件>2048（MB）是正确的。

最后验证方案 #

修改完脚本和Crontab后，手动执行一次脚本，看是否能正确识别超标进程并重启，同时查看日志/var/log/pm2_monitor.log确认没有误触发。之后观察一段时间，应该就能解决无限重启的问题了。

内容的提问来源于stack exchange，提问作者Vaibhav