Linux 如何杀死这个不朽的 nginx 工人？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/18576845/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How to kill this immortal nginx worker?
提问by PaolaJ.
I have started nginx and when I stop like root
我已经启动了 nginx，当我像 root 一样停止时
/etc/init.d/nginx stop
after that I type
之后我输入
ps aux | grep nginx
and get response like tcp LISTEN 2124 nginx WORKER
并得到像 tcp LISTEN 2124 nginx WORKER
kill -9 2124 # tried with kill -QUIT 2124, kill -KILL 2124
and after I type again
在我再次输入之后
ps aux | grep nginx
and get response like tcp LISTEN 2125 nginx WORKERand so on.
并得到诸如此类的回应tcp LISTEN 2125 nginx WORKER。
How to kill this immortal Chuck Norris worker ?
如何杀死这个不朽的查克诺里斯工人？
回答by ash
After kill -9there's nothing more to do to the process - it's dead (or doomed to die). The reason it sticks around is because either (a) it's parent process hasn't waited for it yet, so the kernel holds the process table entry to keep it's status until the parent does so, or (b) the process is stuck on a system call into the kernel that is not finishing (which usually means a buggy driver and/or hardware).
在kill -9此过程无事可做之后- 它已经死了（或注定要死）。它坚持下去的原因是因为（a）它的父进程还没有等待它，所以内核保存进程表条目以保持它的状态直到父进程这样做，或者（b）进程卡在一个未完成的内核系统调用（通常意味着有缺陷的驱动程序和/或硬件）。
If the first case, getting the parent to wait for the child, or terminating the parent, should work. Most programs don't have a clear way to make them "wait for a child", so that may not be an option.
如果是第一种情况，让父节点等待子节点或终止父节点应该可行。大多数程序都没有明确的方法让它们“等待孩子”，因此这可能不是一种选择。
In the second case, the most likely solution is to reboot. There may be tools that could clear such a condition, but that's not common. Depending on just what that kernel processing is doing, it may be possible to get it to unblock by other means - but that requires knowledge of that processing. For example, if the process is blocked on a kernel lock that some other process is somehow holding indefinitely, terminating that other process could aleviate the problem.
在第二种情况下，最可能的解决方案是重新启动。可能有工具可以清除这种情况，但这并不常见。取决于内核处理正在做什么，它可能会通过其他方式解除阻塞 - 但这需要了解该处理。例如，如果该进程被某个其他进程以某种方式无限期持有的内核锁阻塞，则终止该其他进程可能会缓解该问题。
Note that the pscommand can distinguish these two states as well. These show up in the 'Z' state. See the ps man page for more info: http://linux.die.net/man/1/ps. They may also show up with the text "defunct".
请注意，该ps命令也可以区分这两种状态。这些显示在“Z”状态。有关更多信息，请参阅 ps 手册页：http: //linux.die.net/man/1/ps。它们也可能会显示“defunct”文本。
回答by NoorJafri
I was having similar issue.
我有类似的问题。
Check if you are using any auto-healer like Monit or Supervisor which runs the worker whenever you try to stop them. If Yes Disable them.
检查您是否正在使用任何自动修复程序，例如 Monit 或 Supervisor，只要您尝试阻止它们，它们就会运行工作程序。如果是 禁用它们。
My workers were being spawned due to changes I forget i made in update-rc.d in Ubuntu.
由于我忘记了我在 Ubuntu 中的 update-rc.d 中所做的更改，我的工作人员正在生成。
So I installed sysv-rc-confwhich gives a clean interface control of what processes are on reboot, you can disable from there and I assure you no Chuck Noris Resurrection :D
所以我安装了sysv-rc-conf，它提供了一个干净的界面控制重启时的进程，你可以从那里禁用，我向你保证没有 Chuck Noris Resurrection :D
回答by Tiago_nes
I had the same issue. In my case gitlab was the responsible to bring the nginx workers. when i completelly removed gitlab from my server i got able to kill the nginx workers.
我遇到过同样的问题。就我而言，gitlab 负责带来 nginx 工作人员。当我完全从我的服务器中删除 gitlab 时，我能够杀死 nginx 工作人员。
ps -aux | grep "nginx"Search for the workers and check at the first column who is bringing them up.
kill or unistall the responsible and kill the workers again, they will stop spawning ;D
ps -aux | grep "nginx"搜索工人并检查第一列是谁提出他们。
杀死或卸载责任人并再次杀死工人，他们将停止产卵；D
