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

时间:2017-12-21 20:08:14

标签: linux shell unix d pid

我正在开发一个项目,我需要在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>

2 个答案:

答案 0 :(得分:2)

你只需要:

sh -c 'exec command'

shell用你的命令替换它自己,并且没有中间过程。

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

答案 1 :(得分:0)

  

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

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

  

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

不是真的。尝试浏览流程树表明您的方法是错误的。

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