6

在 python 守护进程（使用python-daemon ）中使用多处理模块时出现以下错误：

回溯（最近一次通话最后）：
  _run_exitfuncs 中的文件“/usr/local/lib/python2.6/atexit.py”，第 24 行
    函数（*目标，**卡格斯）
  _exit_function 中的文件“/usr/local/lib/python2.6/multiprocessing/util.py”，第 262 行
    对于 active_children() 中的 p：
  文件“/usr/local/lib/python2.6/multiprocessing/process.py”，第 43 行，在 active_children
    _清理（）
  _cleanup 中的文件“/usr/local/lib/python2.6/multiprocessing/process.py”，第 53 行
    如果 p._popen.poll() 不是无：
  轮询中的文件“/usr/local/lib/python2.6/multiprocessing/forking.py”，第 106 行
    pid, sts = os.waitpid(self.pid, flag)
OSError: [Errno 10] 没有子进程

守护进程（父进程）产生许多进程（子进程），然后定期轮询这些进程以查看它们是否已完成。如果父进程检测到其中一个进程已完成，则它会尝试重新启动该进程。正是在这一点上引发了上述异常。似乎一旦其中一个进程完成，任何涉及多处理模块的操作都会生成此异常。如果我在非守护进程 python 脚本中运行相同的代码，它执行时不会出现任何错误。

编辑：

示例脚本

from daemon import runner

class DaemonApp(object):
    def __init__(self, pidfile_path, run):
        self.pidfile_path = pidfile_path
        self.run = run

        self.stdin_path = '/dev/null'
        self.stdout_path = '/dev/tty'
        self.stderr_path = '/dev/tty'

def run():
    import multiprocessing as processing
    import time
    import os
    import sys
    import signal

    def func():
        print 'pid: ', os.getpid()
        for i in range(5):
            print i
            time.sleep(1)

    process = processing.Process(target=func)
    process.start()

    while True:
        print 'checking process'
        if not process.is_alive():
            print 'process dead'
            process = processing.Process(target=func)
            process.start()
        time.sleep(1)

# uncomment to run as daemon
app = DaemonApp('/root/bugtest.pid', run)
daemon_runner = runner.DaemonRunner(app)
daemon_runner.do_action()

#uncomment to run as regular script
#run()
4

6 回答 6

6

您的问题是守护程序和多处理模块之间的冲突，特别是在处理 SIGCLD（子进程终止）信号时。守护进程在启动时将 SIGCLD 设置为 SIG_IGN，这至少在 Linux 上会导致终止的子进程立即被收割（而不是在父进程调用 wait() 之前成为僵尸）。但是 multiprocessing 的 is_alive 测试调用 wait() 来查看进程是否处于活动状态，如果进程已经被收割，则失败。

最简单的解决方案是将 SIGCLD 设置回 SIG_DFL （默认行为 - 忽略信号并让父进程 wait() 用于终止的子进程）：

def run():
    # ...

    signal.signal(signal.SIGCLD, signal.SIG_DFL)

    process = processing.Process(target=func)
    process.start()

    while True:
        # ...
于 2009-09-16T08:24:54.183 回答
4

忽略SIGCLD也会导致模块出现问题subprocess，因为该模块中存在错误（问题 1731717，截至 2011 年 9 月 21 日仍然开放）。

此行为在库的版本 1.4.8中得到解决python-daemon；它现在省略了对 . 的默认摆弄SIGCLD，因此不再与其他标准库模块有这种不愉快的交互。

于 2009-09-17T15:45:43.063 回答
0

我认为前一段时间在trunk和2.6 maint中进行了修复，这应该有助于解决这个问题，您可以尝试在python-trunk或最新的2.6-maint svn中运行您的脚本吗？我无法提取错误信息

于 2009-09-01T01:01:06.130 回答
0

原始示例脚本具有“导入信号”，但没有使用信号。但是，我有一个导致此错误消息的脚本，这是由于我的信号处理造成的，所以我将在这里解释，以防它发生在其他人身上。在信号处理程序中，我正在处理进程（例如创建一个新进程）。显然这不起作用，所以我停止在处理程序中这样做并修复了错误。（注意：sleep() 函数在信号处理后唤醒，因此如果您需要对进程执行操作，这可以作为对信号进行操作的另一种方法）

于 2009-09-14T20:20:25.107 回答
0

看起来你的错误出现在你的过程的最后——你的线索在你追溯的最开始，我引用......：

File "/usr/local/lib/python2.6/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)

如果atexit._run_exitfuncs正在运行，这清楚地表明您自己的进程正在终止。因此，从某种意义上说，错误本身是一个小问题——只是来自multiprocessing模块注册以从您的进程“退出”运行的某些功能。真正有趣的问题是，为什么你的主进程退出了？我认为这可能是由于一些未捕获的异常：尝试设置异常挂钩并在它被其他异常丢失之前显示丰富的诊断信息，该异常是由多处理为退出运行注册的任何内容引起的......

于 2009-09-01T03:24:06.607 回答
0

我也在使用 RHEL 5.3 和 Python 2.6 下的 celery 分布式任务管理器时遇到了这个问题。我的回溯看起来有点不同，但错误相同：

      File "/usr/local/lib/python2.6/multiprocessing/pool.py", line 334, in terminate
    self._terminate()
  File "/usr/local/lib/python2.6/multiprocessing/util.py", line 174, in __call__
    res = self._callback(*self._args, **self._kwargs)
  File "/usr/local/lib/python2.6/multiprocessing/pool.py", line 373, in _terminate_pool
    p.terminate()
  File "/usr/local/lib/python2.6/multiprocessing/process.py", line 111, in terminate
    self._popen.terminate()
  File "/usr/local/lib/python2.6/multiprocessing/forking.py", line 136, in terminate
    if self.wait(timeout=0.1) is None:
  File "/usr/local/lib/python2.6/multiprocessing/forking.py", line 121, in wait
    res = self.poll()
  File "/usr/local/lib/python2.6/multiprocessing/forking.py", line 106, in poll
    pid, sts = os.waitpid(self.pid, flag)
OSError: [Errno 10] No child processes

非常令人沮丧..我现在通过 pdb 运行代码，但还没有发现任何东西。

于 2009-09-14T06:25:02.973 回答