Sigkill子进程的sh -c“命令”

Question

我正在开发一个项目，我需要在D中松散地重新创建supervisord（作业控制系统）。我使用spawnShell（）而不是spawnProcess（）以便于配置参数等。这具有运行sh -c的效果“命令”。但是，它返回子进程的sh NOT的PID（出于显而易见的原因）。这成为一个问题，因为如果在一段时间后它没有响应SIGTERM，我的程序需要能够向进程发送SIGKILL。我能够发送SIGTERM没问题（大概是因为sh捕获SIGTERM并在退出之前将其传递给它的子进程/进程）。然而，由于显而易见的原因，SIGKILL在有机会向子进程发送信号并且它是孤立的之前停止了。这让我想到了我的问题：

答：我可以安全地假设产生过程的PID总是高于sh的PID吗？到目前为止，它在我的所有测试中都表现得如此。

B：如果没有，那么是否有更优雅的方式（系统调用等）让子进程的PID只知道父进程的PID而不是让我的程序执行pgrep -P <sh PID>？

Answer 1

您只需要：

sh -c 'exec command'

shell用你的命令替换自己并且不用了，所以没有中间过程。

不，你不能认为pids会有一个不同。

Answer 2

我可以安全地假设产生过程的PID总是高于sh的PID吗？到目前为止，它在我的所有测试中都表现得如此。

不，Linux是一个多任务操作系统。虽然很少见，但其他过程可能介于两者之间。不要依赖竞争条件。

如果没有，那么是否有更优雅的方式（系统调用等）让子进程的PID只知道父进程的PID而不是让我的程序执行pgrep -P <sh PID>？

并不是的。尝试导航过程树表明您的方法是错误的。

你正在解决错误的问题。摆脱贝壳中间人。