如何实现一个简单的跨平台Python守护进程？

Question

我想让我的 Python 程序在 Windows 或 Unix 上作为守护进程在后台运行。我看到 python-daemon 包 仅适用于 Unix；有跨平台的替代方案吗？如果可能的话，我希望代码尽可能简单。

Answer 1

在 Windows 中，它被称为“服务”，您可以很容易地实现它，例如使用 win32serviceutil 模块，该模块是 pywin32。不幸的是，这两个“心理模型”——服务与守护进程——在细节上有很大不同，尽管它们服务于相似的目的，而且据我所知，没有 Python 外观试图将它们统一到一个框架中。

Answer 2

这个问题已经有 6 年历史了，但我也遇到了同样的问题，并且现有的答案对于我的用例来说不够跨平台。尽管 Windows 服务的使用方式通常与 Unix 守护程序类似，但归根结底，它们之间存在很大差异，“细节决定成败”。长话短说，我开始尝试找到一些东西，让我能够在 Unix 和 Windows 上运行完全相同的应用程序代码，同时满足对行为良好的 Unix 守护进程的期望（即 在其他地方有更好的解释）在两个平台上尽可能最好：

1. 关闭打开的文件描述符（通常是所有文件描述符，但某些应用程序可能需要保护某些描述符不被关闭）
2. 将进程的工作目录更改为合适的位置以防止“Directory Busy”错误
3. 更改文件访问创建掩码（Python 中的os.umask） world)
4. 将应用程序移至后台，使其与启动进程脱离
5. 完全脱离终端，包括重定向 STDIN、STDOUT 和 STDERR 到不同的流（通常是 DEVNULL），并防止重新获取控制终端
6. 处理信号，特别是 SIGTERM。

跨平台守护进程的根本问题是，Windows 作为一个操作系统，实际上不支持守护进程的概念：从终端启动的应用程序（或在任何其他交互式上下文中，包括从资源管理器启动等）将继续使用可见窗口运行，除非控制应用程序（在本例中为 Python）包含无窗口 GUI。此外，Windows 信号处理严重不足，尝试将信号发送到独立的 Python 进程（而不是子进程，子进程无法在终端关闭中幸存）几乎总是会导致该进程立即退出Python 进程没有任何清理（没有 finally:、没有 atexit、没有 __del__ 等）。

Windows 服务（尽管在许多情况下是可行的替代方案）对我来说基本上是不可能的：它们不是跨平台的，并且需要修改代码。 pythonw.exe （Python 的无窗口版本，随所有最新的 Windows Python 二进制文件一起提供）是更接近，但它仍然没有完全成功：特别是，它无法改善信号处理的情况，并且您仍然无法轻松地从终端启动 pythonw.exe 应用程序并与它在启动期间（例如，向脚本传递动态启动参数，例如密码、文件路径等），在“守护进程”之前。

最后，我决定使用 subprocess.Popen 和 creationflags=subprocess.CREATE_NEW_PROCESS_GROUP 关键字来创建一个独立的无窗口进程：

import subprocess

independent_process = subprocess.Popen(
    '/path/to/pythonw.exe /path/to/file.py',
    creationflags=subprocess.CREATE_NEW_PROCESS_GROUP
)

但是，这仍然给我留下了添加的内容启动通信和信号处理的挑战。对于前者，我的策略是：

1. pickle 启动进程命名空间的重要部分
2. 将其存储在 tempfile 中
3. 添加路径在启动之前在子进程的环境中保存文件
4. 从“守护进程”函数中提取并返回名称空间

对于信号处理，我必须更有创意。在“守护进程”进程中：

1. 忽略守护进程中的信号，因为如上所述，它们都会立即终止进程而不进行清理
2. 创建一个新线程来管理信号处理
3. 该线程启动子信号处理进程并等待它们完成
4. 外部应用程序向子信号处理进程发送信号，导致其终止并完成
5. 这些进程然后使用信号号作为其返回代码
6. 信号处理线程读取返回代码，然后调用用户定义的信号处理程序，或者使用 cytpes API 在 Python 主线程中引发适当的异常
7. 冲洗并重复新信号

总而言之，对于将来遇到此问题的任何人，我推出了一个名为 daemoniker 将适当的 Unix 守护进程和上述 Windows 策略包装到一个统一的外观中。 跨平台 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()

Answer 3

我想到了两个选择：

1. 将程序移植到 Windows 服务。您可能可以在两个实现之间共享大部分代码。

2. 您的程序真的使用任何守护程序功能吗？如果没有，您将其重写为在后台运行的简单服务器，通过套接字管理通信并执行其任务。它可能会比守护程序消耗更多的系统资源，但它将独立于引用平台。

Answer 4

一般来说，守护进程的概念是 Unix 特定的，特别是关于文件创建掩码、进程层次结构和信号处理的预期行为。

您可能会发现 PEP 3143 很有用，其中建议延续 python-daemon 被考虑用于 Python 3.2，并且许多 相关守护进程模块和实现进行了讨论。

Answer 5

它只是unix的原因是守护进程是Unix特定的概念，即后台进程由操作系统启动，通常作为根 PID 的子进程运行。
Windows 没有直接相当于 unix 守护进程，我能想到的最接近的是 Windows 服务。
有一个名为 pythonservice.exe for windows 的程序。不确定是否所有版本的 python 都支持它