我的Python脚本能否生成一个可以无限运行的进程？
我对Python和生成守护进程不太熟悉，因此我想到了这个：
si = subprocess.STARTUPINFO()
si.dwFlags = subprocess.CREATE_NEW_PROCESS_GROUP | subprocess.CREATE_NEW_CONSOLE
subprocess.Popen(executable, close_fds = True, startupinfo = si)
该进程在python.exe进程关闭后继续运行，但一旦我关闭cmd窗口，它也会被关闭。
使用 Janne Karila 提供的答案，以下是运行一个进程的方法，当父进程死亡时子进程不会死亡，而无需使用 win32process 模块。
DETACHED_PROCESS = 8
subprocess.Popen(executable, creationflags=DETACHED_PROCESS, close_fds=True)
DETACHED_PROCESS 是传递给底层的 CreateProcess 函数的一个 进程创建标志。
import subprocess
independent_process = subprocess.Popen(
'python /path/to/file.py',
creationflags=subprocess.CREATE_NEW_PROCESS_GROUP
)
CREATE_NEW_CONSOLE。os.umask）STDIN、STDOUT和STDERR重定向到不同的流（通常是DEVNULL），并防止重新获取控制终端SIGTERM。将应用程序转换为Windows服务虽然在许多情况下是可行的替代方案，但并不完全适合。同样适用于使用pythonw.exe（一种与所有最近的Windows Python二进制文件捆绑在一起的无窗口版本的Python）。特别是它们不能改善信号处理的情况，并且不能轻松地从终端启动应用程序并在启动期间与其进行交互（例如，向脚本提供动态启动参数，例如密码、文件路径等），在"daemonizing"之前。此外，Windows服务需要安装，在第一次调用"daemon"时可以快速运行时进行安装，但这会修改用户的系统（注册表等），如果您来自Unix世界，则这可能会令人意外。
考虑到这一点，我认为使用subprocess.CREATE_NEW_PROCESS_GROUP启动pythonw.exe子进程可能是Python进程在Windows上模拟传统Unix守护进程的最接近等效方式。但是，这仍然需要解决信号处理和启动通信的附加挑战（更不用说使您的代码平台相关，这总是令人沮丧的）。
话虽如此，对于将来遇到这个问题的任何人，我已经编写了一个名为 daemoniker 的库，它包装了正确的Unix守护进程化和上述策略。 它还实现了信号处理（适用于Unix和Windows系统），并允许您使用pickle将对象传递给“守护程序”进程。 最重要的是，它具有跨平台API：
from daemoniker import Daemonizer
with Daemonizer() as (is_setup, daemonizer):
if is_setup:
# This code is run before daemonization.
do_things_here()
# We need to explicitly pass resources to the daemon; other variables
# may not be correct
is_parent, my_arg1, my_arg2 = daemonizer(
path_to_pid_file,
my_arg1,
my_arg2
)
if is_parent:
# Run code in the parent after daemonization
parent_only_code()
# We are now daemonized, and the parent just exited.
code_continues_here()