Неопределенный демонизированный процесс, порождаемый в Python

Я пытаюсь создать демон Python, который запускает другие полностью независимые процессы.

Общая идея заключается в том, чтобы для заданной команды оболочки опрашивать каждые несколько секунд и обеспечивать выполнение точно k экземпляров команды. Мы храним каталог pid-файлов, и при опросе мы удаляем pid-файлы, pid-файлы которых больше не выполняются, и запускаем (и создаем pid-файлы для) любое количество процессов, которые нам нужны, чтобы получить k из них.

Дочерние процессы также должны быть полностью независимыми, чтобы в случае смерти родительского процесса дочерние процессы не были уничтожены. Из того, что я прочитал, кажется, что с модулем subprocess это невозможно сделать. С этой целью я использовал фрагмент, упомянутый здесь:

http://code.activestate.com/recipes/66012-fork-a-daemon-process-on-unix/

Я сделал пару необходимых изменений (вы увидите закомментированные строки в прикрепленном фрагменте):

  1. Исходный родительский процесс не может завершиться, потому что нам нужно, чтобы демон запуска сохранялся бесконечно долго.
  2. Дочерние процессы должны начинаться с того же cwd, что и родительский.

Вот мой spawn fn и тест:

import os
import sys
import subprocess
import time

def spawn(cmd, child_cwd):
    """
    do the UNIX double-fork magic, see Stevens' "Advanced 
    Programming in the UNIX Environment" for details (ISBN 0201563177)
    http://www.erlenstar.demon.co.uk/unix/faq_2.html#SEC16
    """
    try: 
        pid = os.fork() 
        if pid > 0:
            # exit first parent
            #sys.exit(0) # parent daemon needs to stay alive to launch more in the future
            return
    except OSError, e: 
        sys.stderr.write("fork #1 failed: %d (%s)\n" % (e.errno, e.strerror))
        sys.exit(1)

    # decouple from parent environment
    #os.chdir("/") # we want the children processes to 
    os.setsid() 
    os.umask(0) 

    # do second fork
    try: 
        pid = os.fork() 
        if pid > 0:
            # exit from second parent
            sys.exit(0) 
    except OSError, e: 
        sys.stderr.write("fork #2 failed: %d (%s)\n" % (e.errno, e.strerror))
        sys.exit(1) 

    # redirect standard file descriptors
    sys.stdout.flush()
    sys.stderr.flush()
    si = file('/dev/null', 'r')
    so = file('/dev/null', 'a+')
    se = file('/dev/null', 'a+', 0)
    os.dup2(si.fileno(), sys.stdin.fileno())
    os.dup2(so.fileno(), sys.stdout.fileno())
    os.dup2(se.fileno(), sys.stderr.fileno())

    pid = subprocess.Popen(cmd, cwd=child_cwd, shell=True).pid

    # write pidfile       
    with open('pids/%s.pid' % pid, 'w') as f: f.write(str(pid))
    sys.exit(1)

def mkdir_if_none(path):
    if not os.access(path, os.R_OK):
        os.mkdir(path)

if __name__ == '__main__':
    try:
        cmd = sys.argv[1]
        num = int(sys.argv[2])
    except:
        print 'Usage: %s <cmd> <num procs>' % __file__
        sys.exit(1)
    mkdir_if_none('pids')
    mkdir_if_none('test_cwd')

    for i in xrange(num):
        print 'spawning %d...'%i
        spawn(cmd, 'test_cwd')
        time.sleep(0.01) # give the system some breathing room

В этой ситуации кажется, что все работает нормально, и дочерние процессы сохраняются даже после уничтожения родителя. Тем не менее, я все еще сталкиваюсь с лимитом появления исходного родителя. После ~ 650 порождений (не одновременно с завершением дочерних процессов) родительский процесс задыхается с ошибкой:

spawning 650...
fork #2 failed: 35 (Resource temporarily unavailable)

Есть ли способ переписать мою функцию порождения, чтобы я мог бесконечно порождать эти независимые дочерние процессы? Спасибо!


person Ryan N    schedule 08.12.2011    source источник
comment
Как выглядит ваша таблица процессов? Показывает ли ps aux гигантскую кучу процессов-зомби, ожидающих сбора урожая? (Я не вижу здесь никакого кода для wait() для первых разветвленных дочерних элементов.)   -  person sarnold    schedule 08.12.2011
comment
Я так думаю: pastebin.com/qDrFmHWk   -  person Ryan N    schedule 08.12.2011
comment
Рассмотрите возможность использования pyinotify для отслеживания изменений в каталоге вместо опроса.   -  person Jesvin Jose    schedule 08.12.2011


Ответы (2)


Благодаря вашему списку процессов я хочу сказать, что это связано с тем, что вы столкнулись с одним из ряда фундаментальных ограничений:

  • rlimit nproc максимальное количество процессов, которые разрешено выполнять данному пользователю — см. setrlimit(2), встроенный bash(1) ulimit и /etc/security/limits.conf для получения подробной информации об ограничениях процессов для каждого пользователя.
  • rlimit nofile максимальное количество файловых дескрипторов, которое данный процесс может открыть одновременно. (Каждый новый процесс, вероятно, создает три новых канала в родительском для дочерних дескрипторов stdin, stdout и stderr.)
  • Общесистемное максимальное количество процессов; см. /proc/sys/kernel/pid_max.
  • Общесистемное максимальное количество открытых файлов; см. /proc/sys/fs/file-max.

Поскольку вы не пожинаете своих мертвых детей, многие из этих ресурсов остаются открытыми дольше, чем должны. С вашими вторыми дочерними элементами должным образом справляется init(8) — их родитель умер, поэтому они становятся родителями init(8), а init(8) будет убирать за ними (wait(2)), когда они умрут.

Однако ваша программа отвечает за очистку после первого набора дочерних элементов. Программы на C обычно устанавливают обработчик signal(7) для SIGCHLD, который вызывает wait(2) или waitpid(2) для получения статуса выхода потомков и, таким образом, удаления его записей из памяти ядра.

Но обработка сигналов в сценарии немного раздражает. Если вы можете явно установить расположение сигнала SIGCHLD в SIG_IGN, ядро ​​будет знать, что вы не заинтересованы в статусе выхода, и будет пожинать дочерние элементы для вас_.

Попробуйте добавить:

import signal
signal.signal(signal.SIGCHLD, signal.SIG_IGN)

в верхней части вашей программы.

Обратите внимание, что я не знаю, что это делает для Subprocess. Может не порадовать. В этом случае вам нужно установить обработчик сигналов для вызова wait(2) для вас.

person sarnold    schedule 08.12.2011
comment
Предполагается, что подпроцесс обрабатывает магию SIGCHLD. В сочетании с close_fds это должно устранить ошибку в некоторых версиях Python (см. bugs.python.org/issue4216). ). - person ILYA Khlopotov; 08.12.2011
comment
Настройка сигнала и close_fds решили эту проблему для меня на OSX и Ubuntu! Сделал 50к процессов легко. Спасибо вам обоим! - person Ryan N; 08.12.2011
comment
@ILYA: Если бы Subprocess использовался для создания всех процессов, это, вероятно, работало бы нормально; но в этом случае половина процессов создается вручную. - person sarnold; 08.12.2011

Я немного изменил ваш код и смог без проблем запустить 5000 процессов. Так что я согласен с @sarnold, что вы столкнулись с некоторыми фундаментальными ограничениями. Мои модификации:

proc = subprocess.Popen(cmd, cwd=child_cwd, shell=True, close_fds=True)    
pid = proc.pid

# write pidfile       
with open('pids/%s.pid' % pid, 'w') as f: f.write(str(pid))
proc.wait()
sys.exit(1)
person ILYA Khlopotov    schedule 08.12.2011
comment
переключился на: pid = subprocess.Popen(cmd, cwd=child_cwd, shell=True, close_fds=True).pid но все равно не получилось: spawning 647... fork #2 failed: 35 (Resource temporarily unavailable) spawning 648... fork #1 failed: 35 (Resource temporarily unavailable) - person Ryan N; 08.12.2011
comment
close_fds в сочетании с настройкой сигнала отлично сработали для меня! - person Ryan N; 08.12.2011