Ошибка при использовании многопроцессорного модуля в демоне Python

Ubuntu идет с бесплатным программным обеспечением и программным обеспечением с открытым исходным кодом по умолчанию, так собственное программное обеспечение, как программное обеспечение, необходимо играть mp3, не включен в новую установку. Но можно все еще установить его. Нажмите на ссылку ниже или запустите Центр программного обеспечения Ubuntu, оттуда, установите пакет, названный ubuntu-restricted-extras. Это должно решить Вашу проблему.

Install via the software center

Другой способ сделать это состоит в том, чтобы только попытаться играть mp3 файл. Появится сменный поиск. Нажмите Install кнопка после того, как поиск будет завершен. Это также работает.

6
задан Asif Rahman 1 September 2009 в 02:08
поделиться

6 ответов

Игнорирование SIGCLD также вызывает проблемы с модулем подпроцесса из-за ошибки в этом модуле ( проблема 1731717 , все еще открыт с 21.09.2011).

Это поведение исправлено в версии 1.4.8 библиотеки python-daemon ; теперь он не использует стандартные библиотечные функции SIGCLD , поэтому больше не имеет этого неприятного взаимодействия с другими стандартными библиотечными модулями.

4
ответ дан 10 December 2019 в 00:41
поделиться

Я думаю, что недавно было внесено исправление в trunk и 2.6 maint, которое должно помочь в этом. Можете ли вы попробовать запустить свой скрипт в python-trunk или в последней версии 2.6-maint svn? Мне не удается получить информацию об ошибке

0
ответ дан 10 December 2019 в 00:41
поделиться

Похоже, ваша ошибка возникает в самом конце вашего процесса - ваша подсказка находится в самом начале вашей трассировки, и я цитирую ...:

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

if atexit ._run_exitfuncs работает, это ясно показывает, что ваш собственный процесс завершается. Таким образом, сама ошибка в некотором смысле является второстепенной проблемой - просто из-за какой-то функции, которую модуль multiprocessing зарегистрировал для запуска «при выходе» из вашего процесса. Действительно интересный вопрос: ПОЧЕМУ завершается ваш основной процесс? Я думаю, это может быть из-за какого-то неперехваченного исключения: попробуйте установить ловушку исключения и показать обширную диагностическую информацию, прежде чем она будет потеряна из-за ДРУГОГО исключения, вызванного тем, что многопроцессорность зарегистрирована для запуска на выходе ...

0
ответ дан 10 December 2019 в 00:41
поделиться

Я также сталкиваюсь с этим, используя распределенный диспетчер задач сельдерея под RHEL 5.3 с Python 2.6. Моя трассировка выглядит немного иначе, но ошибка та же:

      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, но еще ничего не заметил.

0
ответ дан 10 December 2019 в 00:41
поделиться

Your problem is a conflict between the daemon and multiprocessing modules, in particular in its handling of the SIGCLD (child process terminated) signal. daemon sets SIGCLD to SIG_IGN when launching, which, at least on Linux, causes terminated children to immediately be reaped (rather than becoming a zombie until the parent invokes wait()). But multiprocessing's is_alive test invokes wait() to see if the process is alive, which fails if the process has already been reaped.

Simplest solution is just to set SIGCLD back to SIG_DFL (default behaviour -- ignore the signal and let the parent wait() for the terminated child process):

def run():
    # ...

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

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

    while True:
        # ...
6
ответ дан 10 December 2019 в 00:41
поделиться

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

0
ответ дан 10 December 2019 в 00:41
поделиться
Другие вопросы по тегам:

Похожие вопросы: