我的服务器上有一个严重的进程失控问题。这是一个 Sidekiq（基于 Ruby 的后台作业运行器，用于基于 Rails 的 Web 应用程序），它是我的服务器上最耗 CPU 的应用程序top（技术上，进程名称显示为ruby），它的 PID 不断变化，这表明它不断重新启动。
看起来它曾尝试使用错误的选项运行，因此该进程需要大量 CPU 来初始化（Sidekiq 将我的 Rails 应用程序的整个环境加载到其内存中），然后瞬间死亡。然后某个程序再次使用相同的错误选项重新启动它，重复这个循环并消耗我的服务器性能。我需要找到那个程序并阻止它。
我到目前为止尝试过的：
- 显然，终止进程不会有帮助——我越早终止它，它就会越早重生
重启服务器也没用——
top服务器再次启动后，我一进入服务器就发现了恶意进程Crontab 是空的
我以为有人试图
monit启动 Sidekiq，但 monit 配置与失控进程没有任何关联，而且 - 我只是想monit从服务器中将其全部删除（反正它没有配置，而且处于空闲状态）。完全删除并重新启动后 - 恶意进程仍然存在。
我现在需要追踪是什么导致进程重启。是否有任何可靠的方法可以找到启动进程？还有什么其他方法可用于守护进程，以便在服务器重启后和自身崩溃后运行该进程？任何线索和提示都非常感谢。
PS 那是我自己的临时服务器，不是生产服务器，我在那里有一定的自由度（包括 sudo 和安装或删除软件的权利），但我不会采取诸如完全重新安装操作系统或将带有 sidekiq 配置的应用程序移动到不同文件夹之类的愚蠢举动。我想找到并杀死这个混蛋。是的，那台服务器上有几个操作员，没人记得任何事情。
更新：找到老鼠了！捕捉 PID 或短寿命进程对我来说似乎有点过度设计。我推断重新启动它的东西应该在 /etc 中有配置，所以我做了：
find -H /etc -type f -exec grep -H sidekiq {} \;
问题就在这里，它隐藏在 /etc/init/ 中的一个文件中。只需删除该文件，这个该死的 CPU 消耗者就会立刻消失。