django-sellerie als Systemdienst in virtualenv

Question

Ist es möglich, Django-Sellerie als Systemdienst für ein Projekt in virtualenv zu dämonisieren?

Hier ist meine config:

/etc/systemd/system/celery.service

[Unit] 
Description=Celery Service 
After=network.target 

[Service] 
Type=forking 
User=vagrant 
Group=vagrant 
Restart=no 
WorkingDirectory=/vagrant/myproj/ 
ExecStart=/bin/sh -c '/var/www/vhost/myproj_env/bin/python \ 
    /vagrant/myproj/manage.py celery worker \ 
    --loglevel=DEBUG \ 
    --logfile=/var/log/celery/worker.log \ 
    --pidfile=/var/run/celery/worker.pid \ 
    -Q availability,celery --time-limit=300' 
ExecStop=/bin/sh -c '/var/www/vhost/myproj_env/bin/python \ 
    /vagrant/myproj/manage.py celery stop \ 
    --pidfile=/var/run/celery/worker.pid' 

[Install] 
WantedBy=multi-user.target 

alle hier genannten Verzeichnisse existieren, und die richtig

django-Sellerie Berechtigungen festlegen in settings.py:

INSTALLED_APPS = (
    ... 
    'djcelery', 
    'celery_haystack', 
    ... 
) 

import djcelery 
djcelery.setup_loader() 

CELERYBEAT_SCHEDULER = "djcelery.schedulers.DatabaseScheduler" 
BROKER_URL = "redis://localhost:6379/0" 
CELERY_RESULT_BACKEND = BROKER_URL 
CELERY_REDIS_MAX_CONNECTIONS = 30 

Der folgende Befehl startet Sellerie normalerweise, und ich kann sehen, Aufgaben ausgeführt werden:

python manage.py celery worker --loglevel=INFO -Q availability,celery 

die im Grunde das gleiche wie in den Dienst conf angegeben, außer es an jeden Beitrag stdout

Allerdings, wenn ich zu systemctl start celery.service versuchen, es nicht nur still: systemctl status celery.service Berichte inaktiv (tot)

Ich wäre dankbar für jeden Hinweis auf dieses Problem. Ich könnte etwas offensichtlich fehlt, obwohl ich das Gefühl, dass der Prozess nicht so kompliziert sein sollte, wie es nun ((

UPDATE

Die Sellerie logs sagen, dass Sellerie normal startet, aber für aus irgendeinem Grunde sysctl es nicht akzeptieren Hier ein Ausschnitt aus dem Sellerie Protokoll mit --loglevel = DEBUG ist.!

[2017-07-09 21:55:09,435: DEBUG/MainProcess] | Worker: Preparing bootsteps. 
[2017-07-09 21:55:09,439: DEBUG/MainProcess] | Worker: Building graph... 
[2017-07-09 21:55:09,439: DEBUG/MainProcess] | Worker: New boot order: {Beat, Timer, Hub, Queues (intra), Pool, Autoreloader, StateDB, Autoscaler, Consumer} 
... 
[2017-07-09 21:55:10,696: DEBUG/MainProcess] ^-- substep ok 
[2017-07-09 21:55:10,696: DEBUG/MainProcess] | Consumer: Starting Heart 
[2017-07-09 21:55:10,697: DEBUG/MainProcess] ^-- substep ok 
[2017-07-09 21:55:10,697: DEBUG/MainProcess] | Consumer: Starting event loop 
[2017-07-09 21:55:10,697: WARNING/MainProcess] /var/www/vhost/myproj_env/local/lib/python2.7/site-packages/djcelery/loaders.py:130: UserWarning: Using settings.DEBUG leads to a memory leak, never use this setting in production environments! 
    warn('Using settings.DEBUG leads to a memory leak, never ' 
[2017-07-09 21:55:10,698: WARNING/MainProcess] celery@vagrant ready. 
[2017-07-09 21:55:10,698: DEBUG/MainProcess] | Worker: Hub.register Pool... 
[2017-07-09 21:55:10,699: DEBUG/MainProcess] basic.qos: prefetch_count->4 

es ist die Verarbeitung Aufgaben auch in der Warteschlange

Aber nach 30 Sekunden oder so versagt Sysctl dass Arbeiter zu verstehen, tatsächlich normal funktioniert, und schließt sie:

Job for celery.service failed because a timeout was exceeded. See "systemctl status celery.service" and "journalctl -xe" for details. 

vagrant@vagrant:~$ sudo systemctl status celery.service 
● celery.service - Celery Service 
    Loaded: loaded (/etc/systemd/system/celery.service; enabled; vendor preset: enabled) 
    Active: failed (Result: timeout) since Sun 2017-07-09 21:56:38 UTC; 3min 0s ago 
    Process: 3139 ExecStart=/bin/sh -c /var/www/vhost/myproj_env/bin/python /vagrant/myproj/manage.py c 
    Tasks: 0 
    Memory: 47.4M 
     CPU: 1.532s 

Jul 09 21:55:08 vagrant systemd[1]: Starting Celery Service... 
Jul 09 21:56:38 vagrant systemd[1]: celery.service: Start operation timed out. Terminating. 
Jul 09 21:56:38 vagrant systemd[1]: Failed to start Celery Service. 
Jul 09 21:56:38 vagrant systemd[1]: celery.service: Unit entered failed state. 
Jul 09 21:56:38 vagrant systemd[1]: celery.service: Failed with result 'timeout'. 

NB: Ich habe num der Arbeitnehmer auf eine der Einfachheit halber reduziert und bearbeitet conf-Dateien. Dies machte das Problem etwas klarer (es kein Problem in Sellerie ist, aber wahrscheinlich in systemd), aber ich habe immer noch keine Ahnung, was dieses Timeout verursacht ..

Answer 1

geschaffen, es zu beheben, indem Type=forking von Entfernen/etc/systemd/system/sellery.service