Celery: 작업이 하위 프로세스를 시작할 수 없습니다.

이것은 3.0과 3.1 사이에서 변경되지 않았으므로 지금이 오류가 발생하는 이유를 잘 모르겠습니다.

이것이이 오류를 재현 할 수있는 방법입니다.

app.py :

import multiprocessing
from celery import Celery

app = Celery(__name__, broker='amqp://192.168.33.40')
@app.task
def f():
    manager = multiprocessing.Manager()

sendtask.py :

import app

app.f.delay()

다음 명령을 사용하여 작업자를 실행합니다. celery worker -A app.app -l debug .

Celery 3.0.24로 작업 성공 :

[2013-12-02 20:43:56,454: INFO/MainProcess] Task app.f[bcaab028-dbec-43a8-9259-ff7c35ff13d0] 
succeeded in 0.0169339179993s: None

Celery 3.1.5에서는 다음을 수행하지 않습니다.

[2013-12-02 20:48:38,946: ERROR/MainProcess] Task app.f[c9f1cdd3-ae38-493e-b7c7-b9636ed473d0] 
raised exception: AssertionError('daemonic processes are not allowed to have children',)

문제에 대한 나의 이해는 다음과 같습니다. celery.concurrency.prefork.TaskPool uses celery.concurrency.asynpool.AsynPool ; AsynPool 는 데몬 작업자 프로세스 를 billiard.pool.Pool 에서 상속되며 AsynPool 는이 동작을 재정의하지 않습니다. 하지만 당신 말이 맞습니다.이 계획은 3.0과 3.1 사이에서 변경되지 않은 것 같습니다. 그래서 저도 혼란 스럽습니다. :)

그리고 나는 그 문제에 대해 혼자가 아닌 것 같습니다 : http://stackoverflow.com/questions/20149421/threads-in-celery-3-1-5

한 가지 차이점은 작업자 프로세스가 이제 'Process'의 하위 클래스라는 것입니다. 여기서 함수 인수 Process(target=) 사용하기 전에 이러한 접근 방식의 기본값에 차이가있을 수 있습니다.

멀티 프로세싱 및 이전 버전의 당구 세트 daemon=True :
https://github.com/celery/billiard/blob/2.7/billiard/pool.py#L904

최신 버전에서도 동일합니다.
https://github.com/celery/billiard/blob/3.3/billiard/pool.py#L1039

데몬 인 작업 프로세스는 작업 구현에 심각한 제한이 있다고 생각합니다.
CPU 바운드 작업 속도를 높이기 위해 다중 처리를 사용하는 작업을 작성했습니다. 다음과 같이 터미널에서 작업자를 시작하면 모든 것이 잘 작동합니다.

셀러리 작업자 --app = tasks -Q wb -l info --concurrency = 1

그러나 celeryd 스크립트를 사용하여 작업자를 시작하면 다음 예외가 발생합니다.
AssertionError : 데몬 프로세스는 자식을 가질 수 없습니다.

나는 행동 변화의 원인을 알아 냈다.
작업은 3.0과 3.1 모두에서 데몬 프로세스를 사용하여 실행되지만 celery / billiard @ 4c32d2e 및 https://github.com/celery/billiard/commit/c676b94aa4144349b11ab31c82296a5d804909c9 multiprocessing 모듈이이를 인식하지 못했기 때문에 하위 프로세스 생성을 허용했습니다.

내 이해에 따르면 버전 3.1 이전에는 버그가 있었으며 (작업이 하위 프로세스를 생성 할 수 있었기 때문에 고아 상태가 될 수 있음) 이제이 버그가 수정되었습니다.

파이썬 데몬 프로세스를 포크하지 않기로 한 결정은 나에게 다소 임의적 인 것 같습니다. 나는 그것에 대한 선의를 인정하지만, 내가 선택한다면이 행동을 완전히 통제 할 수 있어야한다고 생각합니다.

작업 당 하나의 프로세스에 묶여 있다는 것은 나에게 심각한 제한 인 것 같습니다. 생각?

왜 그 제한이 처음에 존재하는지 궁금합니다. 다른 수단을 사용하여 프로세스를 완벽하게 포크 할 수있을 때 내가 이해할 수는 있지만 완전히 허용하지 않는 것은 어리석은 것처럼 보입니다.

@ask , 데몬 플래그가 False 인 셀러리 작업자 프로세스를 초기화 할 수 있습니까? 아니면이를 구성 가능하게 만드시겠습니까?

@ilyastam 우리가 동시에 댓글을

나는 그것이 임의의 제한처럼 보인다는 데 동의하지만, 처음에 그것을 추가하는 이유를 알았 으면 좋겠다.

이것은 posix 시스템에서 잘 알려진 함정이지만 여전히 허용됩니다. 신호 처리기에서 자식 프로세스를 정리할 수 있지만 SIGKILL로부터 보호하지는 않습니다.

멀티 프로세싱 동작에서 벗어나더라도 당구에서 제한을 제거해야한다고 생각합니다. 여전히 subpocess 모듈을 사용하거나 하위 수준 fork 호출을 사용하여 하위 프로세스를 만들 수 있으므로 고급 사용자는 하위 billiard.Process 인스턴스를 만들 수 있어야합니다.

@ilyastam raise 문을 제거 할 수 있어야하며 프로세스를 "데몬이 아닌"프로세스로 만들 필요는 없습니다.

즉, 데몬 프로세스는 자식 프로세스를 거둘 수 없더라도 생성 할 수 있습니다.
어쨌든 posix가 작동하는 방식입니다.

Btw, 이것은 raise 가 아니라 assert 문입니다. 파이썬이 PYTHONOPTIMIZE envvar 또는 -O 인수로 시작되면 제거됩니다.

billiard 3.3.0.11은이 변경 사항을 포함하여 PyPI에 있습니다.

@ 감사합니다. 어떤 버전의 셀러리가이 개선을 볼 수 있을지 아십니까?

multiprocessing 문서 는 데몬 프로세스가 하위 프로세스를 만들 수 없음을 명시하고 그 이유를 설명합니다. 저 에게이 assert 문은 raise 대한 바로 가기로 여기에 추가 된 것처럼 보입니다 (사람들은 종종 그렇게합니다).

이 제한은 문서화되어 있으며 Celery가 조용히 multiprocessing 원숭이 패치를 적용하여 제거하는 것은 좋은 생각이 아니라고 생각합니다. 정말 예상치 못한 해로운 결과를 초래할 수 있습니다.

다음 예제를 생각할 수 있습니다 (하지만 약간 인위적으로 보일 수 있습니다).

@app.task
def f():
    p = multiprocessing.Pool(3)
    p.map_async(time.sleep, [1000, 1000, 1000])

일반 Python 함수로 실행되므로이 ​​코드는 올바르게 작동합니다. 그러나 Celery 작업 (Celery 버전 3.0. * 사용)으로 실행되면 영원히 중단되는 세 개의 하위 프로세스가 남습니다. Celery 작업자가 종료되면 이러한 하위 프로세스가 분리됩니다.

이유는 설명하지 않고 자식-자식 프로세스를 시작할 때 예상 할 수있는 유닉스 동작 만 설명합니다. 유닉스에서 악명 높은 제한이지만 사람들이 그렇게하는 것을 막지는 못합니다. 이것은 다르지 않습니다
subprocess.Popen 프로세스를 시작하거나 fork() 를 호출하여 새 프로세스를 시작합니다. 그렇다면 왜 불법이어야합니까?

예제를 수행하는 방법 :

from billiard import Pool
from multiprocessing.util import Finalize

_finalizers = []

@app.task
def f():
    p = billiard.Pool(3)
    _finalizers.append(Finalize(p, p.terminate))
   try:
       p.map_async(time.sleep, [1000, 1000, 1000])
       p.close()
       p.join()
   finally:
       p.terminate()

이것을 (-9) 죽이기 위해서는 자식 프로세스도 -9 죽여야합니다.
모든 유닉스 프로세스를 고려합니다.

모든 작업에 대해 풀 생성을 옹호하는 것은 아니지만 사용자가 자신이 무엇인지 아는 이유는 알 수 없습니다.
작업에서 프로세스를 시작하도록 허용해서는 안됩니다.

또한, 우리는 원숭이 패치를하지 않습니다. 이것은 당구에만있는 변화입니다.

또한, 우리는 원숭이 패치를하지 않습니다. 이것은 당구에만있는 변화입니다.

"원숭이 패치"란 multiprocessing._current_process 를 billiard.process.Process 의 인스턴스로 대체하는이 할당을 의미합니다. https://github.com/celery/billiard/blob/master/billiard/process.py # L53.

나는 (귀하의 예에서와 같이) 올바르게 처리되면 자식-자식 프로세스를 시작하는 데 아무런 문제가 없다는 데 동의합니다. 내 요점은 multiprocessing 가 그렇게 작성되지 않았으며 _implementation_ 제한 사항을 무시해서는 안된다는 것입니다.

@aromanovich 다른 방법으로 쓸 수 없으며 다중 처리의 제한이 아니라 유닉스의 제한입니다.

로깅 모듈 processName 형식 변수가 작동하도록 _current_process를 설정하고 당구 프로세스 개체는 다중 처리 프로세스 개체와 동일한 API를 가지므로 현재 프로세스를 설정하는 것이 안전합니다.

그리고 btw, 당신은 제한을 해제하기 위해 당구를 사용해야 할 것입니다. 다중 처리를 사용하면 여전히 예외가 발생합니다.

이 방법을 사용하여이 문제를 해결할 수도 있습니다.
http://stackoverflow.com/questions/6974695/python-process-pool-non-daemonic
이렇게하면 사용자가 다중 처리 모듈을 계속 사용할 수 있으므로이 문제를 방지 할 수 있습니다.
https://github.com/celery/billiard/issues/99

셀러리 작업 내에서 @parallel fabric 작업을 호출 할

@celery.task
def dostuff():
   execute(fabfile.push_settings, sid=site['sid'])

<strong i="7">@parallel</strong>
@roles(environment)
def push_settings(sid):
  #do stuff

@frodopwns 는 ENV를 사용합니다.
PYTHONOPTIMIZE = 1 내보내기
이 주장을 제거합니다. 모든 것을 처리해야합니다.

@xiaods 나는 다음과 같은 문제를 해결했다고 생각합니다.

@worker_process_init.connect
def configure_workers(sender=None, conf=None, **kwargs):
    Crypto.Random.atfork()

문제

일부 데이터를 계산하고 해당 데이터를 기반으로 예측을 수행하기 위해 scikit-learn 분류기를로드하는 작업이 있습니다. 작업을 단독으로 실행하면 모든 것이 정상이지만 Celery를 사용하여 실행하면 작업이 절인 분류기를로드하려고 할 때 오류가 발생합니다.

[2015-07-17 21:23:51,299: ERROR/MainProcess] Task app.f[329d0da4-2e0e-4e1f-8148-d64f47750b1f] raised unexpected: AttributeError("'Worker' object has no attribute '_config'",)
Traceback (most recent call last):
  File "/home/username/anaconda3/lib/python3.4/site-packages/celery/app/trace.py", line 240, in trace_task
    R = retval = fun(*args, **kwargs)
  File "/home/username/anaconda3/lib/python3.4/site-packages/celery/app/trace.py", line 438, in __protected_call__
    return self.run(*args, **kwargs)
  File "/home/username/working/playground/celery/app.py", line 11, in f
    clf = pickle.load(open('clf.pickle', 'rb'))
  File "/home/username/anaconda3/lib/python3.4/site-packages/sklearn/ensemble/__init__.py", line 6, in <module>
    from .base import BaseEnsemble
  File "/home/username/anaconda3/lib/python3.4/site-packages/sklearn/ensemble/base.py", line 13, in <module>
    from ..externals.joblib import cpu_count
  File "/home/username/anaconda3/lib/python3.4/site-packages/sklearn/externals/joblib/__init__.py", line 112, in <module>
    from .parallel import Parallel
  File "/home/username/anaconda3/lib/python3.4/site-packages/sklearn/externals/joblib/parallel.py", line 23, in <module>
    from ._multiprocessing_helpers import mp
  File "/home/username/anaconda3/lib/python3.4/site-packages/sklearn/externals/joblib/_multiprocessing_helpers.py", line 25, in <module>
    _sem = mp.Semaphore()
  File "/home/username/anaconda3/lib/python3.4/multiprocessing/context.py", line 81, in Semaphore
    return Semaphore(value, ctx=self.get_context())
  File "/home/username/anaconda3/lib/python3.4/multiprocessing/synchronize.py", line 127, in __init__
    SemLock.__init__(self, SEMAPHORE, value, SEM_VALUE_MAX, ctx=ctx)
  File "/home/username/anaconda3/lib/python3.4/multiprocessing/synchronize.py", line 59, in __init__
    kind, value, maxvalue, self._make_name(),
  File "/home/username/anaconda3/lib/python3.4/multiprocessing/synchronize.py", line 117, in _make_name
    return '%s-%s' % (process.current_process()._config['semprefix'],
AttributeError: 'Worker' object has no attribute '_config'

재현하려면

빈 분류기를 만들고 피클로 저장합니다.

import pickle
from sklearn.ensemble import GradientBoostingClassifier
clf = GradientBoostingClassifier()
pickle.dump(clf, open('clf.pickle', 'wb'))

간단한 앱 만들기 ( app.py ) :

import pickle
import sklearn
from celery import Celery

app = Celery(__name__, broker='amqp://localhost//')

@app.task
def f():
    print('hello')
    clf = pickle.load(open('clf.pickle', 'rb'))
    print(clf)

셀러리 작업자를 시작하십시오.

celery -A app worker --loglevel=debug

앱 실행 :

python -c "from app import f; f.delay()"

에러 메시지:

...
AttributeError: 'Worker' object has no attribute '_config'

해결책

특히 과거에 그러한 "기능"이 존재했다면 작업이 하위 프로세스를 시작할 수 있도록 "monkeypatch"Celery 옵션이 있어야한다고 생각합니다. 현재 사람들은이 문제가 발생하면 다른 프레임 워크로 이동하고 있습니다. http://stackoverflow.com/questions/27904162/using-multiprocessing-pool-from-celery-task-raises-exception. 다음은이 오류의 또 다른 예입니다. http://stackoverflow.com/questions/22674950/python-multiprocessing-job-to-celery-task-but-attributeerror.

이 문제는 다시 열어야합니다 ...

나는 방금 같은 문제에 부딪쳤다. 내 작업자 중 하나에서 nltk 를) 사용하고 있습니다. 그러면 scikit-learn 를 가져와 @ostrokach가 보여준 것과 동일한 오류가 발생합니다.

다음 코드로이 문제를 해결할 수있는 것 같습니다.

from celery.signals import worker_process_init

@worker_process_init.connect
def fix_multiprocessing(**kwargs):
    from multiprocessing import current_process
    try:
        current_process()._config
    except AttributeError:
        current_process()._config = {'semprefix': '/mp'}

이것은 분명히 매우 조잡한 해킹이며 실제로 다중 처리를 사용하면 어떻게 될지 모르겠지만 ( semprefix 이 무엇인지조차 모릅니다) scikit-learn 를 만드는 것으로 충분합니다

이 문제가 해결 될 때까지 같은 문제를 겪는 다른 사람들을 위해 여기에 남겨 두겠습니다.

이것이 파이썬 3의 당구와 어떤 종류의 비 호환성일까요? 아니면 Python 2에서도 재현 할 수 있습니까?

셀러리 프로세스의 원래 문제가 하위 프로세스를 만들 수없는 것이 여전히 문제입니까? 댓글을 살펴보면 버전 3.3의 경우 celery / billiard @ e6bb0f7 로 수정되었습니다. 그러나 이후 커밋 (celery / billiard @ c7eedbd0ee1498e76d4fa1affac5b1a275660ee7)은 3.4의 start 메서드에 매우 유사한 assert 문을 다시 도입했습니다. 나는 3.3에 있기 때문에 문제가 없지만 앞으로 문제를 일으킬 수 있는지 지적하고 싶었습니다.

@martinth 감사합니다,이 해킹은 저에게도 효과적입니다!

@xiaods 감사합니다! 귀하의 솔루션이 저에게 효과적입니다! 감사!

@gilinson 여전히 문제이며 PYTHONOPTIMIZE = 1 내보내기는 여전히 "좀 수정"합니다.
Celery 작업에서 ansible 플레이 북을 실행하려고 시도하면서 동일한 문제가 발생했습니다.

@martinth 해킹 주셔서 감사합니다! 다음과 같은 문제가 발생합니다.

• 파이썬 3.4.3
• 셀러리 == 3.1.18
• scikit-learn == 0.17

@martinth 의 해킹은 나를 위해 작동하지 않으며, 일부 계산 속도를 높이기 위해 다중 처리를 사용하려고 시도했습니다. 대신 스레딩 모듈을 사용했으며 여전히 처리를 중단 하면서이 오류를 완화하는 것 같습니다.

스레드 기반 multiprocessing.dummy를 사용하면 셀러리에서 작업했습니다.

from multiprocessing.dummy import Pool

이 오류는 파이썬 2.7.5에서도 여전히 발생합니다. 이 문제를 해결할 의도인지 확실하지 않지만 이로 인해 saltstack의 salt-ssh를 셀러리와 함께 사용할 수 없게됩니다.

이 작업을 완료 할 리소스가 없기 때문에이 작업을 마무리합니다.

가능한 해결책"

스레드를 생성하려는 작업이 있었는데 실패했습니다. 나는 그것을 작동하도록 관리했다 : 똑같은 코드를 수행하는 파이썬 인터프리터로 포크하는 bash 스크립트로 포크 (따라서 내 사용 사례에 중요한 스레드를 만들 수 있음).

티켓이 닫힌 이유를 이해하지 못합니다. 이에 대한 리소스가없는 경우 이에 대해 댓글을 달 수 있지만 티켓이 종료되지는 않습니다. 당신은 그렇게하는 버그를 숨기는 것입니다.

이는 우선 순위와 심각도 모두에서 "중요"라고 표시된 티켓에 특히 나쁩니다.

@orzel +1.
우선 순위 : 중요
심각도 : 위험
이 작업을 완료 할 리소스가 없기 때문에이 작업을 마무리합니다.

농담입니다. 지금 리소스가 없다면 지금 고치지 마십시오. 자원이있을 때 수정하십시오. 티켓을 닫아도 문제가 해결되지는 않습니다.

@orzel @Templarrr 나는이 티켓을 Critical로 분류 했으므로 @ask 가 여기에서 비난하지 않습니다.
당신은 이것에 대해 불행 할 수 있지만 시위는 도움이되지 않습니다.
우리는 실행 가능한 것과 그렇지 않은 것과 현재는 그렇지 않은 것을 기반으로 백 로그를 정리해야합니다.
힘든 전화를 걸지만 누군가는해야합니다.
이 문제가 방해가되는 경우 해결해보십시오. 수정 사항이 정확하고 적절한 테스트가 있으면 병합하겠다고 약속합니다.

뿡뿡
당신은 오해했습니다. 두번.
우리의 관심사는 당신이 자원을 가지고 있지 않다는 것이 아닙니다 (이것은 완벽하게 이해할 수 있고 슬프게도 자유 소프트웨어에서 매우 흔한 경우입니다). 우리의 우려는 그 때문에 티켓이 닫히고 티켓이 작동하는 방식이 아니라는 것입니다.
우리는 '불행'하지 않습니다. 우리는 충격을받습니다.

나는 또한 이것을 닫는 것에 완전히 동의하지 않습니다.

나는 우리 모두가 이것이 실제로 버그라는 데 동의 할 수 있다고 생각합니다. 그리고 _definite_ 버그를 닫는 데 도움이되지 않는 리소스가 충분하지 않다는 것은 정말 슬픈 일입니다. 내일 누군가가 오래 와서 "셀러리의 버그를 고치자"라고 생각하고 미해결 문제를 살펴보고 "글쎄요, 여기서 할 흥미로운 일이 없습니다 ... 대신 _OtherProject_에 ".
또한이 문제를 닫으면 찾기가 더 어려워집니다. Github를 어떻게 사용하는지 모르겠지만 잠재적 인 문제를 발견하면 먼저 이슈 트래커에서 열린 이슈를 검색합니다. 일반적으로 논의가 많고 지금 당장 사용할 수있는 해결 방법도 없습니다 (이 경우와 같이). 내가 _ 정말 _ 절망적 일 때만 나는 닫힌 문제를 살펴보기 시작한다.

이것은 "백 로그 그루밍"이 아니라 숫자 조정입니다. 내가 사용할 것을 보면 미해결 문제 수를 _do_ 봅니다.하지만 항상 별 수 (셀러리의 경우 상당히 높음)도 봅니다. 나는 대중의 호소뿐만 아니라 당신 자신을 위해서도 버그 수를 줄이는 것이 바람직하다는 것을 이해합니다. 솔직히 "250 개의 미해결 문제"를 보는 것은 좋은 숫자가 아니며 압도적으로 들리는 것을 이해합니다.

다음 달 (또는 1 년)에이 작업을 수행 할 인력이 없다면 _ 괜찮습니다 _. 닫지 마세요. 종결은 문제가 완료되거나 _ 절대 완료되지 않을 것임이 _ 절대적으로 명확한 _ 경우에만 발생해야합니다. 둘 다 여기서는 그렇지 않습니다.

"Critical"플래그를 제거하고 지금 처리 할 수 ​​없지만 리소스 _are_를 사용할 수있는 경우 처리해야하는 모든 항목에 대해 "Postponed"플래그를 추가하면됩니다.

실제로 문제를 해결할 수 있을지 모르겠습니다. 유닉스 작동 방식을 변경할 수는 없지만 제한을 해제하기 위해 업스트림 패치를 제출할 수 있습니까?

Linux에 플랫폼 별 솔루션이있을 수 있지만 연구가 필요합니다. 2 년 동안 누구에게도 고칠 인센티브없이 열려 있으므로 가까운 기능에서 고칠 가능성이 낮습니다.

저는 200 개 이상의 문제를 닫고 3 만 개가 넘는 이메일을 읽은 것으로 표시했기 때문에 일부는 논쟁의 여지가 있으며이를 다시 열어야 할 수도 있습니다. 나는 그것을 완전히 기대하지만 우리가 해결책에 기여할 수 있다면 좋을 것입니다. 예를 들어 그것이 유일한 알려진 옵션이라면 결함을 문서화하는 것을 돕는 것입니다.

우리는 자원없이 거대한 프로젝트를 운영하기 위해 노력하고 있습니다. 문제를 분류하거나 이미 수정 된 문제를 찾을 수 없습니다.

음 .. 좋아. 그러나 "셀러리 작업자를위한 코드를 작성하면 멀티 프로세싱을 사용할 수 없습니다"라는 사실이 적어도 문서화 될 수 있습니까? 내 말은 ... 항상 그것을 읽지 않는 사람들이있을 것이지만 적어도 당신은 그것을 가리키고 "봐, 그것은 문서화되었습니다. 우리는 그것을 바꿀 수 없습니다. 그것을 처리하십시오."라고 말할 수 있습니다.

내 할 일 목록은 엄청납니다. 이제 github에서 문서를 직접 편집 할 수 있으므로 다음과 같은 변경 사항을 기여하는 것이 정말 쉽습니다.

나는 문제를 숨기기 위해이 일을하는 것이 아니라 개선되는 것을보고 싶기 때문에 사람들을 정확하게 행동으로 끌어 들이기 위해이 일을합니다.

@ask django에서 celery를 사용하여 작업 내부에 다중 처리를 적용 할 수 있습니까?
그렇게 할 수있는 대안이 있습니까?

@abhisheksachan 그런 질문을 게시하기 전에이 모든 문제를 읽어야합니다

@abhisheksachan 나는 몇 년 동안 이것을 시도하지 않았지만 하위 프로세스의 데몬 화를 허용하기 때문에 https://pypi.python.org/pypi/billiard를 사용하여 작동했습니다.

예, '다중 처리'에서 가져온 가져 오기를 '당구'로 바꿔야합니다. 예를 들면 다음과 같습니다.

from multiprocessing import Process

->

from billiard import Process

다중 처리 제한을 비활성화 할 수있는 방법은 없지만 어쨌든 제한이 있어서는 안된다고 주장하므로 다중 처리 포크가 허용합니다.

저를 좋아하는 사람은 대기열 시스템 개발에 투자했습니다. _BEFORE_ 그 제한 사항을 알아 내고 더 유용한 rabbitMQ 파이썬 래퍼로 마이그레이션 할 수있을 때까지 다른 해결 방법이 필요합니다. 깨끗하게 포크하십시오. 분기 된 프로세스는 이제 셀러리 샌드 박스 외부에 있으며 정상적으로 작동합니다.

OP 예에서 다음을 바꿉니다.

app = Celery(__name__, broker='amqp://192.168.33.40') 
@app.task
def f():
    manager = multiprocessing.Manager()

와:

app = Celery(__name__, broker='amqp://192.168.33.40')
@app.task
def f():
    process = subprocess.Popen(["program"]) # or the newer post 3.5 run version
    process.wait()
    # analyze exit code

"프로그램"은 다음과 같습니다 (POSIX 유닉스 / 리눅스 플랫폼에서).

import os

def main():
      manager = multiprocessing.Manager()

# this is equivalent to "(cmd )&" under bash
pid = os.fork()
if pid == 0:
    cpid = os.fork()
    if cpid == 0:
        main()
    else:
        exit(0)
else:
    os.wait(pid)

CPU 관리는 셀러리를 사용한다는 생각에 어긋나는 셀러리의 범위를 벗어나지 만 다중 처리를 사용하려는 경우 어쨌든 셀러리 외부에서 CPU 사용을 처리하고 싶을 것입니다.

최소한 그 제한은 문서화되어야합니다. 문서를 둘러 보았지만 찾을 수 없었습니다.

다시 말하지만, 문서 변경 사항과 함께 풀 요청을 자유롭게 제출하십시오.

@martinth 의 의견 에 따라 Python 3.5.2, Celery 4.0.0 및 billiard 3.5.0에 대한 그의 솔루션은 작동하지 않았습니다. 다중 처리가 데몬 화되는 프로세스를 확인하고 자식을 시작하지 못하도록 막기 때문입니다.

작업자의 데몬 플래그를 재설정하여 제한을 해제 할 수있었습니다. 나는 그것이 나쁜 생각이라고 확신하지만 셀러리 작업 내에서 다중 처리를 시작할 수 있습니다.

@worker_process_init.connect
def fix_multiprocessing(**kwargs):
    # don't be a daemon, so we can create new subprocesses
    from multiprocessing import current_process
    current_process().daemon = False

즉, IMHO Celery는 작업자를 데몬으로 시작할지 여부를 구성하는 문서화 된 옵션을 추가해야합니다. 참고 저는 k8 포드에서 셀러리를 사용하고 있으므로 셀러리는 celery worker 사용하여 포 그라운드 프로세스로 시작되며 데몬 화 된 작업자 가 필요 하지 않습니다.

@miraculixx 이 제안의 문제는 처리 할 실패 모드와 해결해야 할 문제가 더 많다는 것입니다. 차라리 피하고 싶습니다.

멀티 프로세싱을 프리 포크 풀과 함께 사용하면 실패하지만 솔로 풀을 사용하면 작동하는 것 같습니다. 따라서 해결 방법은 프리 포크 풀에 여러 자녀가있는 셀러리 작업자가 아닌 솔로 풀로 여러 셀러리 작업자를 생성하는 것입니다. 합법적으로 들립니까? 물론 그렇게하면 max-mem-per-child와 같은 일부 옵션이 작동하지 않습니다.

이것은 기본적으로 응용 프로그램 디자인 문제라고 생각합니다. daemonic processes are not allowed to have children 직면 한 특별한 고통입니다. 아시다시피 전체 애플리케이션을 다시 디자인해야하는 시점에 도달했기 때문입니다. 그러나 그것은 OS 레벨 제한이며 심각한 부작용 없이는 피할 수 없습니다. 데몬 프로세스는 또한 C에서 자식을 가질 수 없습니다. 이것은 파이썬과 관련된 것이 아닙니다. 쓰레드 대 프로세스 성능에 대한 논쟁이 있었는데, 결론적으로 어느 것도 다른 것보다 훨씬 더 좋거나 나쁘다는 것이 밝혀지지 않았습니다.

두 가지 옵션을 제안합니다 (여기서 셀러리가 아니라 일반적으로 이야기).

• subprocess.Popen 를 사용하여 자식을 가질 수 있고 프로세스 간 통신을 위해 UNIX 소켓을 사용할 수있는 독립 프로세스를 생성합니다.
• 스레드가 기본 프로세스가 아닌 분기 된 프로세스에 의해 생성되는 것이 정말로 필요합니까?

그만한 가치가있는 경우, 그 당시의 사용 사례는 사소하지 않은 (그리고 보안에 민감하지 않은) 입력 문제로 인해 종종 빠르게 충돌하는 장기 실행 하위 프로세스를 시작하고 싶었습니다. 그래서 아이디어는 적어도 프로세스가 성공적으로 시작되었는지 확인하는 것이 었습니다.

장기적으로 여러 가지 이유로 설계 불량으로 판명되었으므로 새로운 아키텍처는 자연스럽게 비동기 셀러리 작업자의 "자연스러운"사용으로 되돌아갔습니다. 그래서 나는 포크가 정말로 필요한지에 대한 질문에 동의합니다. 태스크는 포크입니다.

그만한 가치를 위해, 내 사용 사례는 (joblib를 통해) 다중 처리를 사용하는 scikit-learn 프로세스를 시작하는 것이 었습니다. 나는 이후로 joblib에 대한 셀러리 백엔드를 개발했습니다. 즉, scikit-learn은 셀러리를 사용하여 병렬 프로세스를 시작하고 위의 해킹이 더 이상 필요하지 않습니다. 이것은 POC 단계에 있으며 아직 황금 시간대가 아닙니다.

@miraculixx 이건 어딘가에 호스팅 했나요? 살펴 보거나 시도해보고 싶습니다. 저는 여러분과 동일한 문제인 sklearn 스폰 하위 프로세스에 직면하고 있으며 기본적으로 Celery를 포기했습니다.

@pgeez sklearn 에서 하위 프로세스를 사용하지 않으려면 환경 변수 JOBLIB_MULTIPROCESSING = 0을 설정할 수 있습니다. https://github.com/scikit-learn/scikit-learn/blob/0.18.X/sklearn/externals/joblib/_multiprocessing_helpers.py 참조

@jennaliu 생각에 감사하지만 @miraculixx 처럼 멀티 프로세싱을 활성화해야합니다.

셀러리의 데몬 프로세스에서 아이들을 거부하기 위해 오래된 유닉스 더블 포크 트릭 을 시도해 보셨습니까?

이 스레드의 제목을 읽었습니까?!?!?

@sebastroy 분명히 수년 동안이 스레드를 따라 왔습니다. 방금 이중 포크를 발견했지만 이제는 데몬 포크가 샐러리에 의해 죽임을 당하고 있다고 생각하는 것이 혼란 스러웠습니다.

알았어. 예 전생에 저는 C를 사용하고 있었기 때문에 이것은 빵과 버터 같았습니다.

내가 사용하는 해결 방법은 잘 작동하는 subprocess.Popen이지만 셀러리가 먼저 수행해야하는 일부 논리를 다시 구현하고 프로그램의 셸 버전을 만들어야합니다. 하지만 최상위 API 구현의 동작을 변경하여 수정했습니다. 셀러리의 목적과 더 일치한다고 생각합니다. 너무 낮은 수준의 로직도 단순화하십시오.

다행히도 Celery 작업에서 ansible 플레이 북을 실행하려고 할 때이 문제를 발견합니다.
@martinth 가 제공 한 방법은 저에게 current_process()._config 인쇄하고
{'authkey': b"y&e\x8d'\xcb\xd4\r\xd2\x86\x06\xe7\x9e\x14\xaf \xbc\xc4\x95\xa5G\xec&[i\x19\xf3G-\x06\xac\x19", 'semprefix': '/mp', 'daemon': True}
그런 다음 daemon 필드를 False 다시 할당하면 작동합니다.

작업에서 다중 프로세스를 실행할 수있는 몇 가지 솔루션 또는 기타 구현이 있습니까?

@HeartUnchange : 최근 우리는 분산 구성 요소로 셀러리를 사용하고자하는 빅 데이터 프로젝트를 열심히 진행하고 있습니다. 그리고 당신의 가이드와 함께, 우리는 문제를 해결하게되어 운이 좋습니다. 작업 구성을 참조하십시오.

     @app.task
    def handleBigZipfile(filename,nid):
    current_process()._config['daemon'] = False
    logger.info('{} begin handle!'.format(filename))
    handleAll(filename,nid)
     logger.info('{} is done!'.format(filename))

해결책은 괜찮습니다! 2017.1에서 프로젝트를 시작하고 이제 프로토 타입이 완성되었습니다! 9 개월이 지났습니다! 나는 당신에게 감사합니다! 그리고 내 감사는 표현할 수 없습니다!
문제를 어떻게 파악했는지 자세히 설명해 주시겠습니까? 우리는 그것을 알고 싶어합니다!

안녕하세요 ,

나는 꽤 표준적인 설정을 가지고있다 : Django + Rabbitmq + celery-4.0.2 + python-2.7 + centOS-7

셀러리에서 표준 파이썬 다중 처리 모듈을 사용하여 프로세스를 생성하려고합니다.

데몬 프로세스는 자식 프로세스를 만들 수 없으며 결과적으로 다중 처리 패키지를 사용하는 작업이 작동하지 않습니다.
실행에 사용 된 명령 : celery worker -B -A celery_task -l debug
역 추적 로그 :

[2017-09-26 23:27:08,838: WARNING/PoolWorker-2] ERROR
[2017-09-26 23:27:08,839: WARNING/PoolWorker-2] Traceback (most recent call last):
[2017-09-26 23:27:08,839: WARNING/PoolWorker-2] File "/home/induser/config.py", line 612, in main
[2017-09-26 23:27:08,840: WARNING/PoolWorker-2] mylog_process = mp.Process(target=test_logger_process, args=(myqueue,))
[2017-09-26 23:27:08,840: WARNING/PoolWorker-2] File "/usr/lib64/python2.7/multiprocessing/process.py", line 98, in __init__
[2017-09-26 23:27:08,841: WARNING/PoolWorker-2] self._authkey = _current_process._authkey
[2017-09-26 23:27:08,841: WARNING/PoolWorker-2] AttributeError: 'Process' object has no attribute '_authkey'

프로세스를 생성하지 않는 이유는 무엇일까요?
다음은 코드입니다.

import multiprocessing as mp
from celery.schedules import crontab
from celery.decorators import periodic_task

@periodic_task(run_every=crontab(minute='*/1'), name='test_process_celery')
def main():
data = config_read()
try:
    myqueue = mp.Queue(-1)
    mylog_process = mp.Process(target=test_logger_process, args=(myqueue,))
    mylog_process.start()
    . . .
    . . .
except Exception as e:
    raise
finally:
    mylog_process.join()

감사합니다.

마스터를 시도하고 여전히 문제인지보고하십시오.

여전히 오류가 있습니다. 다음과 함께 하위 프로세스를 사용하려고했습니다.

from multiprocessing import Process, Value
import ctypes

[...]
        result = Value('i', 0)
        text = Value(ctypes.c_char_p, fail_string.encode())
        p = Process(target=reader.find_text_async, args=(result, text, ))
        p.start()
        p.join(5)

        if p.is_alive():
            logging.WARNING("Manual terminating the process 'find_text_async'")
            p.terminate()

그러나 셀러리 마스터 브랜치 에서는 다음과 같이 말합니다.

파일 "/usr/lib/python3.5/multiprocessing/process.py", 103 행, 시작
'데모닉 프로세스는 자녀를 가질 수 없습니다'
AssertionError : 데몬 프로세스는 자식을 가질 수 없습니다.

편집하다

당구로 멀티 프로세싱을 변경했는데 효과가 있습니다!

from billiard import Process, Value