Ubuntu идет с бесплатным программным обеспечением и программным обеспечением с открытым исходным кодом по умолчанию, так собственное программное обеспечение, как программное обеспечение, необходимо играть mp3, не включен в новую установку. Но можно все еще установить его. Нажмите на ссылку ниже или запустите Центр программного обеспечения Ubuntu, оттуда, установите пакет, названный ubuntu-restricted-extras
. Это должно решить Вашу проблему.
Другой способ сделать это состоит в том, чтобы только попытаться играть mp3 файл. Появится сменный поиск. Нажмите Install
кнопка после того, как поиск будет завершен. Это также работает.
Игнорирование SIGCLD
также вызывает проблемы с модулем подпроцесса
из-за ошибки в этом модуле ( проблема 1731717 , все еще открыт с 21.09.2011).
Это поведение исправлено в версии 1.4.8 библиотеки python-daemon
; теперь он не использует стандартные библиотечные функции SIGCLD
, поэтому больше не имеет этого неприятного взаимодействия с другими стандартными библиотечными модулями.
Я думаю, что недавно было внесено исправление в trunk и 2.6 maint, которое должно помочь в этом. Можете ли вы попробовать запустить свой скрипт в python-trunk или в последней версии 2.6-maint svn? Мне не удается получить информацию об ошибке
Похоже, ваша ошибка возникает в самом конце вашего процесса - ваша подсказка находится в самом начале вашей трассировки, и я цитирую ...:
File "/usr/local/lib/python2.6/atexit.py", line 24, in _run_exitfuncs
func(*targs, **kargs)
if atexit ._run_exitfuncs
работает, это ясно показывает, что ваш собственный процесс завершается. Таким образом, сама ошибка в некотором смысле является второстепенной проблемой - просто из-за какой-то функции, которую модуль multiprocessing
зарегистрировал для запуска «при выходе» из вашего процесса. Действительно интересный вопрос: ПОЧЕМУ завершается ваш основной процесс? Я думаю, это может быть из-за какого-то неперехваченного исключения: попробуйте установить ловушку исключения и показать обширную диагностическую информацию, прежде чем она будет потеряна из-за ДРУГОГО исключения, вызванного тем, что многопроцессорность зарегистрирована для запуска на выходе ...
Я также сталкиваюсь с этим, используя распределенный диспетчер задач сельдерея под 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, но еще ничего не заметил.
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:
# ...
В исходном примере сценария есть "сигнал импорта", но сигналы не используются. Однако у меня был сценарий, вызывающий это сообщение об ошибке, и это было связано с моей обработкой сигнала, поэтому я объясню здесь, если это происходит для других. В обработчике сигналов я работал с процессами (например, создавал новый процесс). По-видимому, это не работает, поэтому я перестал делать это в обработчике и исправил ошибку. (Примечание: функции sleep () просыпаются после обработки сигнала, поэтому это может быть альтернативным подходом к действию на сигналы, если вам нужно что-то делать с процессами)