sh -c“命令”的子进程
我正在进行一个项目，在这个项目中，我需要在D中松散地重新创建监督for (作业控制系统)。为了便于配置参数等，我使用spawnShell()而不是spawnProcess()。这具有运行sh -c“命令”的效果。但是，它返回sh的PID，而不是子进程的PID(原因很明显)。这成为一个问题，因为我的程序需要能够发送一个SIGKILL到进程，如果它没有响应SIGTERM在一段时间后。我能够发送一个SIGTERM没有问题(大概是因为sh捕获了SIGTERM并在退出之前将它传递给它的子进程/进程)。但是，由于同样明显的原因，SIGKILL在获得向子进程发送信号的机会之前停止sh，并且使它成为孤儿。这让我想到了我的问题：
答:我能安全地假设衍生进程的PID总是比sh的PID高吗？到目前为止，它在我所有的测试中都是这样的。
B:如果没有，那么比让我的程序只执行pgrep -P <sh PID>更优雅的方法(系统调用之类的)来获取子进程的PID只知道父进程的PID
回答 2
Stack Overflow用户
发布于 2017-12-21 20:27:02
你只需要：
sh -c 'exec command'shell用您的命令替换自己，然后退出，因此没有中间进程。
不，您不能假设pids会有一个不同。
Stack Overflow用户
发布于 2017-12-21 20:10:20
我是否可以安全地假设生成的进程的PID总是高于sh的PID？到目前为止，它在我所有的测试中都是这样的。
不是的。Linux是一个多任务操作系统。虽然很少，但其他过程可能在两者之间开始。不要依赖种族的条件。
如果没有，那么是否有一种更优雅的方法(系统调用之类的)来获得子进程的PID只知道父进程的PID而不是让我的程序执行
pgrep -P <sh PID>？
不怎么有意思。试图导航过程树是一个迹象，表明您的方法是错误的。
你在解决错误的问题。干掉那个空壳中间人。
https://stackoverflow.com/questions/47932054
复制相似问题
腾讯云开发者
