Celery: Les tâches ne sont pas autorisées à démarrer des sous-processus

Cela n'a pas changé entre 3.0 et 3.1, donc je ne sais pas pourquoi vous obtiendriez cette erreur maintenant et pas avant.

C'est ainsi que cette erreur peut être reproduite.

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()

Je lance worker en utilisant la commande suivante: celery worker -A app.app -l debug .

Avec Celery 3.0.24, la tâche réussit:

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

Avec Celery 3.1.5, il ne:

[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',)

Ma compréhension du problème est la suivante: celery.concurrency.prefork.TaskPool utilise celery.concurrency.asynpool.AsynPool ; AsynPool hérite de billiard.pool.Pool qui génère des processus de travail démon et AsynPool ne remplace pas ce comportement. Mais vous avez raison, ce schéma ne semble pas être changé entre 3.0 et 3.1, donc je suis aussi confus :)

Et il semble que je ne sois pas seul avec ce problème: http://stackoverflow.com/questions/20149421/threads-in-celery-3-1-5

Une différence est que le processus de travail est maintenant une sous-classe de 'Process', où avant d'utiliser l'argument de fonction: Process(target=) , il y a peut-être une différence dans les valeurs par défaut pour ces approches.

multitraitement et anciennes versions des ensembles de billard daemon=True :
https://github.com/celery/billiard/blob/2.7/billiard/pool.py#L904

Et c'est pareil dans la dernière version:
https://github.com/celery/billiard/blob/3.3/billiard/pool.py#L1039

Je pense que le processus de tâche étant un démon présente une limitation sérieuse pour la mise en œuvre des tâches.
J'ai écrit une tâche qui utilise le multitraitement pour accélérer les opérations liées au processeur. Tout fonctionne bien lorsque je démarre un ouvrier dans un terminal comme suit:

céleri ouvrier --app = tâches -Q wb -l info --concurrency = 1

Mais lorsque j'utilise le script celeryd pour démarrer un worker, j'obtiens cette exception:
AssertionError: les processus démoniaques ne sont pas autorisés à avoir des enfants

J'ai compris ce qui avait provoqué le changement de comportement.
Les tâches sont exécutées à l'aide de processus démon à la fois dans 3.0 et 3.1, mais jusqu'à ce que celery / billiard @ 4c32d2e et https://github.com/celery/billiard/commit/c676b94aa4144349b11ab31c82296a5d804909c9 multiprocessing module n'en était pas conscient et par conséquent permettait de créer des sous-processus.

À ma connaissance, il y avait un bogue avant la version 3.1 (les tâches étaient autorisées à créer des sous-processus, ce qui pouvait entraîner un état orphelin) et maintenant ce bogue a été corrigé.

La décision de ne pas autoriser les processus de démon python à bifurquer me semble plutôt arbitraire. Bien que j'en reconnaisse la bonne foi, je pense que je devrais être en mesure d'avoir un contrôle total sur ce comportement si je le souhaite.

Être lié à un processus par tâche me semble être une sérieuse limitation. Pensées?

Je me demande pourquoi cette limitation est là en premier lieu, un avertissement que je peux comprendre, mais le rejeter purement et simplement semble ridicule lorsque vous êtes parfaitement capable de bifurquer des processus en utilisant d'autres moyens.

@ask , serait-il possible d'initialiser le processus de travail du céleri avec l'indicateur de démon False? Ou rendre cela configurable?

@ilyastam semble que nous commentions en même temps

Je conviens que cela semble être une limitation arbitraire, mais j'aurais aimé connaître la raison d'être de son ajout en premier lieu.

C'est un piège bien connu dans les systèmes posix, mais il est toujours autorisé. Vous pouvez nettoyer les processus enfants dans un gestionnaire de signaux, bien que cela ne vous protège pas contre SIGKILL.

Je pense que nous devrions supprimer la limitation du billard, même si cela divergerait du comportement multitraitement. Vous pouvez toujours créer des processus enfants en utilisant le module subpocess ou en utilisant l'appel de bas niveau fork , donc les utilisateurs expérimentés devraient pouvoir créer des instances enfants billiard.Process .

@ilyastam Devrait être capable de supprimer l'instruction rise, pas besoin de rendre les processus "non-démon"

Autrement dit, les processus démons seront autorisés à créer des processus enfants même s’ils ne pourront pas les récolter,
c'est comme ça que posix fonctionne de toute façon.

Btw, notez que ce n'est pas une raise , c'est une instruction assert, qui sera supprimée si python est démarré avec l'argument PYTHONOPTIMIZE envvar ou -O .

billiard 3.3.0.11 est sur PyPI, y compris ce changement

@ask merci. Une idée de la version du céleri qui verra cette amélioration?

multiprocessing indique explicitement que les processus démons ne sont pas autorisés à créer des sous - cette déclaration assert ressemble plus à ce qu'elle a été placée ici comme un raccourci pour raise (les gens le font souvent).

Cette limitation est documentée et je ne pense pas que ce soit une bonne idée pour Celery de patcher silencieusement un singe multiprocessing et de l'enlever. Cela pourrait avoir des conséquences vraiment inattendues et néfastes.

Je peux penser à l'exemple suivant (cela peut sembler un peu artificiel, cependant):

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

Étant exécuté comme une simple fonction Python, ce code fonctionne correctement. Mais étant exécuté en tant que tâche Celery (en utilisant Celery version 3.0. *), Il laisse trois sous-processus qui seront suspendus pour toujours; lorsque l'ouvrier Celery quitte, ces sous-processus deviennent orphelins.

Cela n'explique pas pourquoi, il indique simplement le comportement Unix auquel vous vous attendez lors du démarrage d'un processus enfant-enfant. Même si c'est une limitation infâme dans unix, cela n'empêche pas les gens de le faire. Ce n'est pas différent de
démarrer un processus subprocess.Popen , ou même appeler fork() pour démarrer un nouveau processus. Alors pourquoi devrait-il être illégal?

La façon de faire votre exemple:

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()

Pour tuer (-9) cela, vous devrez également tuer -9 les processus enfants, mais c'est quelque chose que vous aurez
à prendre en compte pour tous les processus Unix.

Non pas que je préconise de créer un pool pour chaque tâche, mais je ne vois pas pourquoi les utilisateurs, qui savent ce qu'ils
faire, ne devrait pas être autorisé à démarrer des processus à partir d'une tâche.

De plus, nous ne corrigeons rien de singe, il s'agit uniquement d'un changement de billard.

De plus, nous ne corrigeons rien de singe, il s'agit uniquement d'un changement de billard.

Par "monkey patching", j'entends cette affectation, qui remplace multiprocessing._current_process par une instance de billiard.process.Process : https://github.com/celery/billiard/blob/master/billiard/process.py # L53.

Je conviens qu'il n'y a rien de mal à démarrer des processus enfant-enfant s'ils sont bien gérés (comme dans votre exemple). Mon point est que multiprocessing n'est pas écrit de cette façon et nous ne devons pas ignorer ses limitations de _implémentation_.

@aromanovich Cela ne peut pas être écrit autrement, ce n'est pas une limitation du multitraitement, c'est une limitation d'unix.

Il définit _current_process afin que la variable de format des modules de journalisation processName fonctionne, et que l'objet de processus de billard ait la même API que l'objet de processus multitraitement afin qu'il soit sûr de définir le processus actuel.

Et d'ailleurs, vous devrez utiliser le billard pour que la limitation soit levée, l'utilisation du multitraitement lèvera toujours l'exception.

Pourrait également résoudre ce problème en utilisant cette approche:
http://stackoverflow.com/questions/6974695/python-process-pool-non-daemonic
Ce qui permettrait aux utilisateurs de continuer à utiliser le module multitraitement, évitant ce problème:
https://github.com/celery/billiard/issues/99

J'obtiens cette erreur lors de l'appel d'une tâche de tissu

@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 utilise ENV
export PYTHONOPTIMIZE = 1
pour supprimer cette affirmation. vous devez gérer toutes choses.

@xiaods Je pense avoir résolu ce problème avec quelque chose comme ceci:

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

Problème

J'ai une tâche qui calcule certaines données et charge un classificateur scikit-learn pour faire des prédictions basées sur ces données. Lorsque j'exécute la tâche par elle-même, tout va bien, mais lorsque je l'exécute à l'aide de céleri, j'obtiens une erreur lorsque la tâche tente de charger le classificateur mariné:

[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'

Reproduire

Créez un classificateur vide et enregistrez-le sous forme de cornichon:

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

Créez une application simple ( 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)

Démarrez le céleri-ouvrier:

celery -A app worker --loglevel=debug

Exécutez l'application:

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

Message d'erreur:

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

Solution

Je pense qu'il devrait y avoir une option pour "monkeypatch" Celery pour permettre aux tâches de démarrer des sous-processus, surtout si une telle "fonctionnalité" existait dans le passé. À l'heure actuelle, les gens s'éloignent simplement vers d'autres frameworks lorsqu'ils rencontrent ce problème: http://stackoverflow.com/questions/27904162/using-multiprocessing-pool-from-celery-task-raises-exception. Voici un autre exemple de cette erreur: http://stackoverflow.com/questions/22674950/python-multiprocessing-job-to-celery-task-but-attributeerror.

Ce numéro devrait être rouvert ...

Je viens de rencontrer le même problème. J'utilise nltk dans l'un de mes workers qui à son tour importe scikit-learn ce qui conduit à la même erreur que @ostrokach a montrée.

Il semble que je puisse contourner ce problème avec le code suivant:

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'}

C'est évidemment un hack très grossier et je ne sais pas ce qui se passerait si j'utilisais vraiment le multitraitement (diable je ne sais même pas ce qu'est semprefix ) mais c'est suffisant pour faire scikit-learn travailler à nouveau.

Je laisse cela ici pour d'autres personnes qui trébuchent sur le même problème jusqu'à ce que ce problème soit résolu.

Serait-ce une sorte d'incompatibilité avec le billard sur Python 3? Ou est-il également reproductible sur Python 2?

Le problème initial des processus de céleri ne pouvant pas créer de sous-processus est-il toujours un problème? En regardant en arrière dans les commentaires, cela a été corrigé avec celery / billiard @ e6bb0f7 pour la version 3.3. Cependant, un commit ultérieur (celery / billiard @ c7eedbd0ee1498e76d4fa1affac5b1a275660ee7) a réintroduit une instruction assert très similaire dans la méthode de démarrage pour 3.4. Aucun problème pour moi puisque je suis sur 3.3, mais je voulais juste le signaler si cela pouvait créer des problèmes dans le futur.

@martinth Merci, ce hack fonctionne pour moi aussi!

@xiaods Merci! Votre solution fonctionne pour moi! Merci!

@gilinson c'est toujours un problème et exporter PYTHONOPTIMIZE = 1 le "corrige en quelque sorte".
Je viens de rencontrer le même problème, en essayant d'exécuter un playbook ansible dans la tâche Celery

@martinth Merci pour le hack! Je rencontre le même problème avec:

• Python 3.4.3
• céleri == 3.1.18
• scikit-learn == 0,17

Le hack de @martinth ne fonctionne pas pour moi, j'ai rencontré ce

L'utilisation du multiprocessing.dummy basé sur les threads a fonctionné dans le céleri pour moi:

from multiprocessing.dummy import Pool

Cette erreur se produit également dans python 2.7.5. Je ne sais pas s'il est destiné à y remédier, mais cela rend l'utilisation de salt-ssh de saltstack inutilisable avec du céleri.

Clôture, car nous n'avons pas les ressources pour mener à bien cette tâche.

Solution possible"

J'avais une telle tâche qui essayait de créer des threads et cela échouerait. J'ai réussi à le faire fonctionner en: forçant à un script bash qui lui-même renvoie à un interpréteur python qui fait exactement le même code (et pourrait donc créer des threads, ce qui était essentiel pour mon cas d'utilisation).

Je ne comprends pas pourquoi le ticket est fermé. Si vous ne disposez pas de ressources pour cela, vous pouvez faire un commentaire à ce sujet, mais cela ne ferme pas le ticket. Vous cachez simplement le bogue en le faisant.

Ce qui est particulièrement mauvais pour un ticket étiqueté «critique» à la fois pour la priorité et la gravité.

@orzel +1.
Priorité: critique
Gravité: critique
Clôture, car nous n'avons pas les ressources pour mener à bien cette tâche.

C'est une blague. Si vous n'avez pas de ressources maintenant, ne le réparez pas maintenant. Corrigez-le lorsque vous aurez des ressources. La fermeture du ticket ne résoudra pas le problème

@orzel @Templarrr J'ai étiqueté ce ticket comme critique, donc @ask n'est pas à blâmer ici.
Vous pourriez être mécontent de cela, mais protester n'aidera pas.
Nous devons préparer notre arriéré en fonction de ce qui est exploitable et de ce qui ne l'est pas et actuellement ce n'est pas le cas.
C'est un appel difficile à faire, mais quelqu'un doit le faire.
Si ce problème vous gêne, essayez de le résoudre. Je promets que si le correctif est correct et a les tests appropriés, je le fusionnerai.

@thedrow
Tu as mal compris. À deux reprises.
Notre souci n'est pas que vous n'ayez pas la ressource (c'est parfaitement compréhensible, et, malheureusement, un cas très courant dans le logiciel libre). Notre préoccupation est que le ticket est fermé à cause de cela, ce n'est pas ainsi que les tickets fonctionnent.
Nous ne sommes pas «malheureux», nous sommes choqués.

Je suis également complètement en désaccord avec la fermeture de ceci.

Je pense que nous pouvons tous convenir que ce _is_ en effet un bogue. Et bien qu'il soit en effet triste qu'il n'y ait pas assez de ressources, la fermeture d'un bogue _definite_ n'aidera pas cela. Vous ne pouvez pas savoir si peut-être que demain quelqu'un arrive longtemps et pense "corrigeons quelques bugs dans Celery" juste pour examiner les problèmes en suspens et pense "Eh bien, il n'y a pas de travail intéressant à faire ici ... travaillons sur _OtherProject_ à la place ".
De plus, la fermeture de ce problème rendra sa recherche plus difficile. Je ne sais pas comment vous utilisez Github, mais lorsque je découvre un problème potentiel, je recherche d'abord dans le suivi des problèmes un problème ouvert. Généralement, il y a beaucoup de discussions et plus jamais il n'y a aussi une solution de contournement (comme dans ce cas) que je peux utiliser pour le moment. Ce n'est que si je suis vraiment désespéré que je commence à examiner les problèmes fermés.

Ce n'est pas du «toilettage de l'arriéré», c'est un ajustement des nombres. Si je regarde les choses à utiliser, je regarde le nombre de problèmes ouverts, mais je regarde aussi toujours le nombre d'étoiles (qui est assez élevé pour le céleri). Je comprends qu'il est souhaitable d'avoir un faible nombre de bogues pour l'attrait du public, mais aussi pour votre propre bien. Honnêtement, je comprends que voir "250 problèmes en suspens" n'est pas un bon nombre et semble accablant.

Si vous n'avez pas la main-d'oeuvre pour travailler là-dessus dans le prochain mois (ou même l'année) _c'est bien_. Ne fermez pas. Une clôture ne devrait se produire que si le problème est résolu ou si il est "absolument clair" qu'il ne sera "jamais_ fait". Les deux ne sont pas le cas ici.

Supprimez simplement les indicateurs «Critique» et ajoutez un indicateur «Reporté» pour tout ce qui ne peut pas être géré maintenant mais qui devrait être géré si la ressource _est_ disponible.

Je ne suis pas sûr que nous puissions résoudre le problème. Nous ne pouvons pas changer le fonctionnement d'Unix mais nous pourrions soumettre un correctif en amont pour lever la restriction?

Il existe peut-être des solutions spécifiques à la plate-forme sous Linux, mais cela devrait être recherché. Il est ouvert depuis 2 ans sans que personne ne soit incité à le réparer, il est donc peu probable qu'il soit corrigé dans la fonction proche.

J'ai fermé plus de 200 problèmes et marqué plus de 30 000 e-mails comme lus, donc certains d'entre eux sont forcément litigieux et nous devrons peut-être les rouvrir. Je m'attends complètement à cela, mais ce serait bien si nous pouvions également contribuer à une solution, par exemple en aidant à documenter le défaut si c'est la seule option connue.

Nous sommes débordés de travail, essayant de gérer un énorme projet sans ressources. Nous ne sommes pas en mesure de trier les problèmes ou de savoir quels problèmes ont déjà été résolus.

Bien, OK. Mais est-ce que le fait que «vous ne pouvez pas utiliser le multitraitement si vous écrivez du code pour un céleri ouvrier» pourrait au moins être documenté? Je veux dire ... il y aura toujours des gens qui ne le liront pas, mais au moins vous pouvez le pointer vers lui et dire "Voyez, c'est documenté. Nous ne pouvons pas le changer.

Ma liste de tâches est gigantesque, vous pouvez maintenant éditer la documentation directement sur github, donc c'est vraiment facile d'apporter des modifications comme celles-ci :(

Je ne fais pas cela pour cacher des problèmes, je le fais pour inciter les gens à agir précisément parce que je veux que cela s'améliore.

@ask Pouvons-nous appliquer le multitraitement à l'intérieur de la tâche en utilisant le céleri dans Django?
Y a-t-il une alternative pour le faire?

@abhisheksachan, vous devriez lire tout ce problème avant de publier une telle question

@abhisheksachan Je n'ai pas essayé cela depuis quelques années, mais je l'avais fait fonctionner en utilisant https://pypi.python.org/pypi/billiard car il permet la démonisation des sous-processus.

Ouais, vous devez remplacer les importations de 'multiprocessing' par 'billiard', par exemple:

from multiprocessing import Process

->

from billiard import Process

Il n'y a aucun moyen pour nous de désactiver la limitation du multitraitement, mais nous soutenons qu'il ne devrait pas y avoir de limitation de toute façon, donc notre fourchette de multitraitement le permet.

Pour tous ceux qui, comme moi, ont investi dans le développement d'un système de mise en file d'attente _ AVANT_ découvrir cette limitation et ont besoin d'une solution de contournement différente jusqu'à ce qu'ils puissent migrer vers un wrapper python rabbitMQ plus utilisable, j'ai réussi à contourner le problème en appelant un sous-processus externe qui peut fourchez-vous proprement. Ce processus fourchu est maintenant en dehors du bac à sable de céleri et les choses fonctionnent comme il se doit.

Dans l'exemple OP, remplacez:

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

avec:

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

et le "programme" ressemblera à (sous la plateforme POSIX unix / linux)

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)

Gardez à l'esprit que la gestion du processeur échappe à la portée du céleri, ce qui va un peu à l'encontre de l'idée d'utiliser le céleri, mais étant donné que vous alliez utiliser le multitraitement, vous voudrez probablement gérer l'utilisation du processeur en dehors du céleri de toute façon.

À tout le moins, cette limitation devrait être documentée. J'ai regardé autour de moi dans le document et je n'ai pas trouvé.

Encore une fois, n'hésitez pas à soumettre une demande d'extraction avec les modifications de la documentation.

suivi @martinth de commentaire sur Python 3.5.2, 4.0.0 et Céleri billard 3.5.0 sa solution n'a pas fonctionné, comme les contrôles de multitraitement sur le processus en cours daemon et il arrête de démarrer un enfant.

J'ai pu lever la restriction en réinitialisant l'indicateur de démon du travailleur. Je suis à peu près sûr que c'est une mauvaise idée, mais cela permet de démarrer le multiprocessing.Pools à partir d'une tâche de céleri.

@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

Cela dit, IMHO Celery devrait ajouter une option documentée pour configurer s'il démarre les travailleurs en tant que démons. Remarque J'utilise du céleri dans une cosse k8, donc le céleri est démarré en tant que processus de premier plan en utilisant celery worker , et je n'ai vraiment pas besoin de travailleurs démonisés.

@miraculixx Le problème avec cette suggestion est que nous aurons plus de modes d'échec à gérer et plus de problèmes à résoudre. Nous préférons les éviter.

Bien que l'utilisation du multitraitement échoue en combinaison avec le pool préfork, cela semble fonctionner lors de l'utilisation du pool solo. Donc, je suppose qu'une solution de contournement serait de faire apparaître plusieurs céleris avec le pool solo, au lieu d'un avec plusieurs enfants dans le pool prefork. Cela vous semble-t-il légitime? Bien sûr, de cette façon, certaines options telles que max-mem-per-child ne fonctionneront pas.

Je pense qu'il s'agit essentiellement d'un problème de conception d'application. C'est une douleur particulière pour daemonic processes are not allowed to have children , car vous savez, vous avez atteint un point où vous devez repenser l'ensemble de l'application. Mais c'est une limitation au niveau du système d'exploitation, vous ne pouvez pas la contourner sans effets secondaires graves. Les processus démoniaques ne peuvent pas non plus avoir d'enfants en C. Ce n'est pas un truc spécifique à Python. Il y avait autrefois un débat sur les performances des threads et des processus, et en conclusion, aucun d'entre eux n'est significativement meilleur ou pire que l'autre.

Je suggère deux options (et en parlant en général, pas de céleri ici)

• Utilisez subprocess.Popen pour générer un processus indépendant, qui peut avoir des enfants et utiliser des sockets UNIX pour la communication inter-processus
• Est-il vraiment nécessaire que les threads soient générés par un processus fourchu et non par votre processus principal?

Pour ce que cela vaut, mon cas d'utilisation à l'époque était que je voulais lancer un sous-processus de longue durée qui se plantait souvent rapidement en raison de problèmes d'entrée non triviaux (et non sensibles à la sécurité). L'idée était donc au moins de s'assurer que le processus se lance avec succès.

Il s'est avéré à long terme une conception médiocre pour diverses raisons, de sorte que la nouvelle architecture est naturellement revenue à l'utilisation «naturelle» des céleris asynchrones. Je suis donc d'accord avec l'idée de se demander si la fourche est vraiment nécessaire; la tâche est la fourchette.

pour ce que ça vaut, mon cas d'utilisation était de lancer des processus scikit-learn qui utilisent le multitraitement (via joblib). J'ai depuis développé un backend de céleri vers joblib, ce qui signifie que scikit-learn lance des processus parallèles utilisant du céleri et que mon hack ci-dessus n'est plus nécessaire. Ceci est dans une étape POC, pas encore prêt pour les heures de grande écoute.

@miraculixx Avez-vous cela hébergé quelque part? J'aimerais y jeter un œil et / ou l'essayer. Je rencontre le même problème que vous - sklearn engendrant des sous-processus - et j'ai pratiquement abandonné le céleri.

@pgeez Si vous ne vous souciez pas de l'utilisation de sous-processus dans sklearn, vous pouvez définir la variable d'environnement JOBLIB_MULTIPROCESSING = 0. Voir https://github.com/scikit-learn/scikit-learn/blob/0.18.X/sklearn/externals/joblib/_multiprocessing_helpers.py

@jennaliu merci pour cette réflexion, mais comme @miraculixx , j'ai besoin d'

Avez-vous essayé la vieille astuce Unix à double fourchette pour désavouer les enfants du processus démon du céleri?

Avez-vous lu le titre de ce fil?!?!?

@sebastroy évidemment, je suis ce fil depuis des années. Je viens de découvrir la double fourchette, mais je vois maintenant que ma confusion était de penser que les fourchettes de démon étaient tuées par du céleri, pas qu'elles étaient carrément empêchées.

Je t'ai eu. Ouais dans ma vie précédente, j'utilisais du C donc c'était comme du pain et du beurre.

La solution de contournement que j'utilise est subprocess.Popen qui fonctionne bien, mais vous devez ensuite réimplémenter une certaine logique (et créer une version shell du programme), c'est ce que le céleri devrait faire en premier lieu. Mais je l'ai corrigé en modifiant le comportement de l'implémentation de l'API de niveau supérieur. Je pense que c'est plus conforme au but du céleri. Simplifiez aussi une certaine logique que le bas niveau.

Heureusement, je trouve ce problème lorsque j'essaie d'exécuter un playbook ansible dans la tâche Celery.
La méthode fournie par @martinth n'a pas fonctionné pour moi. J'imprime le current_process()._config et j'obtiens
{'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} .
Ensuite, je réaffecte le champ daemon à False , et cela fonctionne.

Existe-t-il des solutions ou d'autres implémentations pour permettre l'exécution de multiprocessus dans la tâche?

@HeartUnchange : récemment, nous travaillons dur sur un projet Big Data, que nous souhaitons utiliser le céleri comme composant distribué. et avec votre guide, nous sommes très chanceux de résoudre le problème. voir la configuration de la tâche:

     @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))

La solution est ok! nous commençons le projet à 2017.1 et maintenant le prototype est terminé! neuf mois se sont écoulés! Je vous remercie! et mes remerciements sont au-delà de l'expression!
pourriez-vous décrire plus en détail comment vous résolvez le problème! nous avons hâte de le savoir!

Salut ,

J'ai une configuration assez standard: Django + Rabbitmq + celery-4.0.2 + python-2.7 + centOS-7

J'essaie de créer un processus en utilisant le module multiprocesseur standard de python dans le céleri.

Les processus démons ne sont pas autorisés à créer des processus enfants et, par conséquent, les tâches qui utilisent un package multiprocesseur ne fonctionnent pas:
Commande utilisée pour exécuter: céleri worker -B -A celery_task -l debug
Journaux de suivi:

[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'

Quelle pourrait être la raison de ne pas engendrer le processus?
Voici le code:

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()

Merci.

essayez master et signalez si c'est toujours le problème

Il a toujours l'erreur. J'ai essayé d'utiliser un sous-processus avec:

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()

mais avec la branche principale de céleri ça sais:

Fichier "/usr/lib/python3.5/multiprocessing/process.py", ligne 103, au début
'Les processus démoniaques ne sont pas autorisés à avoir des enfants'
AssertionError: les processus démoniaques ne sont pas autorisés à avoir des enfants

ÉDITER

J'ai changé le multitraitement avec le billard et ça marche!

from billiard import Process, Value