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 回答