这种转瞬即逝的高负载进程真的很闹心，我之前维护服务器的时候也碰到过类似的“幽灵进程”，给你整理几个落地的排查思路，一步步来揪出它：

一、用auditd实时捕获进程执行详情 #

auditd是系统自带的审计工具，能精准记录进程的创建动作，哪怕进程立刻退出也能留下完整痕迹：

• 先确保auditd安装并运行：sudo apt install auditd && sudo systemctl start auditd
• 添加针对root用户python进程的审计规则：

  sudo auditctl -a exit,always -F arch=b64 -F euid=0 -F exe=/usr/bin/python -S execve
  

  这条规则会记录所有root用户执行的python进程的execve系统调用（也就是进程启动的核心动作）
• 实时监控审计日志，等进程出现的时候就能抓到完整信息：

  sudo tail -f /var/log/audit/audit.log | grep -i "execve"
  

  日志里会包含进程的实际工作目录、完整命令行、脚本的绝对路径这些关键信息，刚好能解决你找不到run.py位置的问题

二、用execsnoop抓短命进程 #

execsnoop是bcc工具集里的神器，专门用来捕获转瞬即逝的进程，用法更直观：

• 先安装bcc工具包：sudo apt install bcc
• 启动针对root用户python进程的捕获：

  sudo execsnoop -u root -n python
  

  只要root用户一启动python进程，不管它活多久，这个命令都会立刻输出进程的PID、命令行、执行路径，甚至退出时间，完全不用跟PID赛跑

三、排查定时任务触发源 #

短暂反复出现的进程大概率是定时任务在搞鬼，重点查这几个地方：

• 查看root用户的个人定时任务：sudo crontab -l
• 检查系统级定时任务目录：

  ls -la /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/
  

  这些目录里的脚本可能会触发目标进程，哪怕脚本里是调用了其他路径的run.py
• 检查anacron的任务记录：sudo cat /var/spool/anacron/*，它负责处理错过执行的定时任务，也可能是触发源

四、搜索系统中所有run.py脚本 #

既然进程里明确出现了run.py，不如先把系统里所有的run.py都找出来，逐个排查内容：

sudo find / -name "run.py" -type f | grep -v "/proc/"

（排除/proc目录是因为里面的是进程虚拟文件，不是实际脚本）
找到后可以查看每个run.py的内容，看看有没有start-queue相关的逻辑，以及是否有被root用户执行的可能

五、用持续进程采样补漏 #

如果上面的工具都没抓到，还可以用循环采样的方式把所有进程的快照记录到文件里，等进程出现后去查历史：

while true; do ps auxf | grep -E "python|run.py" >> /tmp/process_snapshots.log; sleep 0.1; done

这个命令会每0.1秒把包含python或run.py的进程信息写到/tmp/process_snapshots.log里，等进程出现后，你去这个文件里找对应的PID和命令行，就能拿到更多细节

备注：内容来源于stack exchange，提问作者lusk