Python程序仍在运行但找不到PID

Question

我正在后台运行一个与父程序分离的子程序。退出父程序后，我希望子程序继续运行并登录到OUTPUT_PATH。事实上，我可以看到日志文件正在更新。然而，当我试图从 ps aux 中找到 PID 时，我找不到它。谁能解释这种行为？我做错了什么？

 shellCommand = "nohup python PYTHON_PROGRAM ARGS >OUTPUT_PATH 2>&1 &" 
 subprocess.Popen(shellCommand, shell=True, preexec_fn=os.setpgrp) 

Answer 1

好吧，这对于评论来说太大了。通过运行 ps -fwp $(pgrep -f PYTHON_PROGRAM) ，我们现在找到了该进程。 :) 但它的 PID 与 Popen.pid 报告的不匹配。这将取决于您使用 shell=True 后调用的 shell 实例。第一个 fork 是调用 shell，第二个是用于您的脚本。实际上，这已记录在上面提到的链接中:

Note that if you set the shell argument to True, this is the process ID of the spawned shell.

但请参阅下面的注释。

这给我们带来了“更正统的方式”。我们正在进入可能有争议的领域，不同的人，不同的想法。也许不像第一个那样符合documentation建议不要使用 shell=True 除非确实需要。

args is required for all calls and should be a string, or a sequence of program arguments. Providing a sequence of arguments is generally preferred, as it allows the module to take care of any required escaping and quoting of arguments (e.g. to permit spaces in file names). If passing a single string, either shell must be True (see below) or else the string must simply name the program to be executed without specifying any arguments.

还有另一节介绍不听从建议的(安全)影响。

因此，编译参数列表以使用脚本运行 nohup 并通过关键字参数(stdout、stderr)处理输出重定向) 的 Popen 看起来是一个很好的做法，并且还会为您提供一致的 PID。

最后一步可能会引起最大的争议:但实际上您可以通过相应系统调用的 python 接口(interface)来守护进程。有据可查的示例似乎会在 github 中增长(从下面提到的 PEP 中的链接到达一跳)。

或者有一个library引用PEP-3143就主题而言。

<小时/>

注意:该位似乎并不总是正确(调用 sh 是的，但两个 PID 不是)。至少在我的系统上，我观察到 sh 可以 exec 通过 -c (本身)调用的程序，而无需 fork 。从几次快速运行和跟踪来看，至少如果我没有弄乱 stdin/-out/-err (即没有管道或重定向)，没有强制子 shell (...) ，或者没有通过 ; 链接命令。 (后两者是显而易见的，一旦您意识到重定向是如何实现的，前两者也是显而易见的)。因此，至少对于我的 shell，我敢于推断并说:它似乎不会 fork ，除非必须 fork 。或者更简化(因此不完全正确)的说法是:简单的东西不会 fork 。