问题描述
假设，我启动了一个父进程，它启动了一个子进程，但是父进程收到了一个 SIGINT.我希望父进程退出，但我不希望子进程逗留和/或成为僵尸.我需要确保它死了.
Suppose, I launch a parent process, which launches a subprocess, but then the parent receives a SIGINT. I want the parent to exit, but I don't want the child process to linger and/or become a zombie. I need to make sure it dies.
如果我可以确定孩子也收到了 SIGINT，那么它可能正在自行清理.在这种情况下，我更愿意在它完成并自行退出时短暂等待.但是，如果它没有收到 SIGINT，那么我会立即向它发送一个 SIGTERM(或 SIGKILL)，并让父进程处理它自己的清理.
If I can determine that the child also received a SIGINT, then it is probably cleaning up on its own. In that case, I'd prefer to briefly wait while it finishes and exits on its own. But if it did not receive a SIGINT, then I will send it a SIGTERM (or SIGKILL) immediately and let the parent proceed with its own cleanup.
我如何确定孩子是否收到了SIGINT?(撇开它甚至可能不响应 SIGINT 的事实...)我是否只需要根据父进程是否在前台进程组中运行来猜测?如果 SIGINT 以编程方式发送，而不是通过 Ctrl+C 发送会怎样?
How can I figure out if the child recevied the SIGINT? (Leaving aside the fact that it might not even respond to SIGINT...) Do I just have to guess, based on whether or not the parent is running in the foreground process group? What if the SIGINT was sent programmatically, not via Ctrl+C?
推荐答案
也许你不能.对您而言，重要的是孩子是否处理 SIGINT(它可能会忽略它).请参阅我对您其他问题的回答.
Perhaps you can't. And what should matter to you is if the child handled SIGINT (it could have ignored it). See my answer to your other question.
然而，在很多情况下， 发送的信号被发送到一个进程组.那么你可能也收到了那个信号.
However, in many cases, the signal sent by was sent to a process group. Then you might have got that signal too.
在病理情况下，您的整个系统进行了颠簸，并且子进程有甚至还没有被安排去处理信号.
In pathological cases, your entire system experiments thrashing and the child process had not even being scheduled yet to process the signal.
我希望父进程退出，但我不希望子进程逗留和/或变成僵尸.我需要确保它死了.
也许你想在某个地方使用 daemon(3) ?
Maybe you want to use somewhere daemon(3) ?
这篇关于父进程能否确定其子进程是否收到了 SIGINT?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！