Наблюдение за сельдереем с супервизором и virtualenv
Мой celerybeat.conf
[program:celerybeat]
command=/path/app/env/bin/celery beat -A project.tasks --loglevel=INFO
environment=PYTHONPATH=/path/app/env/bin
user=nobody
numprocs=1
stdout_logfile=/var/log/celeryd.log
stderr_logfile=/var/log/celeryd.log
autostart=true
autorestart=true
startsecs=10
stopwaitsecs = 600
killasgroup=true
priority=998
Когда я запускаю диспетчер, я получаю сообщение об ошибке:
pidfile_fd = os.open(self.path, PIDFILE_FLAGS, PIDFILE_MODE)
celery.platforms.LockFailed: [Errno 13] Permission denied: '/celerybeat.pid'
Есть идеи, как это решить?
Ответы
Ответ 1
Проблема в том, что вы не указали какой-либо каталог в файле конфигурации, а каталог по умолчанию - "/" (root), который у вашего пользователя не имеет прав на запись.
Настройка пользователя как root решила вашу проблему, потому что теперь у вас было разрешение на запись в '/', однако это может быть не лучшее решение. Существует несколько способов решения этой проблемы, включая:
-
Добавьте переменную каталога в конфигурацию и укажите путь, к которому у пользователя есть права на запись.
directory=<path>
-
Предоставьте аргумент pidfile команде celery, которую вы используете, чтобы запустить сельдерей. Убедитесь, что у вас есть права на запись для пути, который вы указываете для pidfile.
command=/path/app/env/bin/celery beat -A project.tasks --loglevel=INFO --pidfile=/tmp/celerybeat-myapp.pid
Ответ 2
Вот моя (рабочая) версия для Celere beat:
[program:celery_periodic]
command=<venv_path>/bin/python <path>/manage.py celery worker --loglevel=info -c 1 -E -B -Q celery_periodic -f <log_folder>/celery_periodic.log -n periodic_worker
directory=<path>
user=<some_user>
group=<some_user>
autostart=true
autorestart=true
redirect_stderr=True
daemon = False
debug = False
stdout_logfile = NONE
stderr_logfile = NONE
loglevel = "info"
Возможно, это поможет.
Также проверьте разрешения на папку, в которой вы создаете файл pid.
Ответ 3
Я решаю свою проблему, установив user = root, но я думаю, что это плохой способ...
Ответ 4
Я столкнулся с аналогичной проблемой. Это было исправлено изменением 2 настроек:
- как упоминалось выше: добавление --pidfile =/tmp/celerybeat-myapp.pid
- user = "фактический пользователь без полномочий root"
Значение по умолчанию, указанное в некоторой документации "user = nobody", кажется, вызывает дополнительные ошибки прав доступа с помощью celerybeat.conf (но не в celery.conf).