我已经启动了nginx，当我像root一样停止时
/etc/init.d/nginx stop
之后我输入
ps aux | grep nginx
得到像tcp LISTEN 2124 nginx WORKER的回应
kill -9 2124 # tried with kill -QUIT 2124, kill -KILL 2124
然后我再次打字
ps aux | grep nginx
并获得像tcp LISTEN 2125 nginx WORKER等响应。
如何杀死这个不朽的查克诺里斯工人？
在kill -9之后，没有什么可以做的事情 - 它已经死了（或者注定要死）。它坚持的原因是因为（a）它的父进程还没有等待它，所以内核保存进程表条目以保持它的状态，直到父进程这样做，或者（b）进程被卡在系统调用未完成的内核（通常意味着有缺陷的驱动程序和/或硬件）。
如果第一种情况，让父母等待孩子，或终止父母，应该工作。大多数程序没有明确的方法让它们“等待孩子”，所以这可能不是一个选择。
在第二种情况下，最可能的解决方案是重新启动。可能有工具可以清除这种情况，但这并不常见。根据内核处理正在做什么，有可能通过其他方式使其解除阻塞 - 但这需要了解该处理。例如，如果进程在内核锁上被阻止某个其他进程以某种方式无限期地保留，则终止该进程可能会缓解该问题。
请注意，ps命令也可以区分这两种状态。这些出现在'Z'状态。有关更多信息，请参见ps手册页：http://linux.die.net/man/1/ps。他们也可能会出现“已解散”的文字。
我遇到过同样的问题。在我看来，gitlab负责带来nginx工作者。当我完全从我的服务器中删除gitlab时，我能够杀死nginx工作者。
ps -aux | grep "nginx"- 搜索工作人员并在第一列检查谁。
- 杀死或卸下负责人并再次杀死工人，他们将停止产卵; D.
我有类似的问题。
检查您是否正在使用任何自动治疗器，如Monit或Supervisor，当您试图阻止它们时，它会运行工作人员。如果是，则禁用它们。
由于我忘记了我在Ubuntu的update-rc.d中所做的更改，我的工作人员正在催生。
所以我安装了sysv-rc-conf，它为重启时的进程提供了一个干净的界面控制，你可以从那里禁用，我向你保证没有Chuck Noris Resurrection：D