Question

这是否可以将django-celery作为virtualenv中项目的系统服务进行守护？

这是我的配置：

/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

此处提到的所有目录都存在，并且权限设置正确

logo.py中的django-celery：

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

以下命令正常启动芹菜，我可以看到正在执行的任务：

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

除了发布到stdout

之外，它与服务conf中指定的基本相同

然而，当我尝试systemctl start celery.service时，它只是默默地失败：systemctl status celery.service报告无效（死机）

我会对这个问题的暗示表示感谢。我可能会遗漏一些明显的东西，虽然我觉得这个过程不应该像现在这样复杂（（

更新

芹菜日志告诉我，芹菜正常启动，但由于某种原因，sysctl不接受它。以下是来自芹菜日志的片段，其中包含--loglevel = DEBUG：

[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

甚至在队列中处理任务！

但是在30秒左右后，sysctl无法理解该工作人员实际上是否正常运行，并将其关闭：

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

注意：为简单起见，我减少了一些工作人员，并编辑了conf文件。这使得问题更加清晰（这不是芹菜中的问题，但可能在systemd中），但我仍然不知道是什么导致了这个超时..

Answer 1

设法通过从 /etc/systemd/system/celery.service

中删除Type=forking来解决此问题

django-celery作为virtualenv中的系统服务

1 个答案: