![作为 Supervisord 子进程运行 shell 脚本?](https://linux22.com/image/658511/%E4%BD%9C%E4%B8%BA%20Supervisord%20%E5%AD%90%E8%BF%9B%E7%A8%8B%E8%BF%90%E8%A1%8C%20shell%20%E8%84%9A%E6%9C%AC%EF%BC%9F.png)
我有一个 Django 1.6.2 应用程序,它使用 Celery 3.1.7 执行异步任务。我正在使用 Supervisor 启动我的 Celery 工作进程。到目前为止,除了我重新启动 Debian 7.8 服务器之外,一切都运行良好。当发生这种情况时,我的 Celery 工作进程不会重新启动,因为当服务器重新启动时,它会将 celery 日志文件的所有权从我的“celery”用户更改为“root”。此外,系统会删除我写入 pid 文件的 /run/celery 目录。如果我手动进行这些更改并重新启动 Celery,我的所有工作进程都会正常启动。
由于这些更改需要在启动工作者之前进行,我认为解决方案是编写一个 shell 脚本,由于其优先级较高,它会在 celery 工作者命令之前从我的supervisor.conf 脚本中执行(见下文)。
但是,这个安装脚本无法运行。我的主管日志只显示:
exited: celery-setup (exit status 0; not expected)
gave up: celery-setup entered FATAL state, too many start retries too quickly.
此外,没有错误写入 stdout/err 日志文件。
我的问题是:
这是在 celery 工作者重新启动之前更改我的工作者日志权限和重新创建 pid 目录的正确方法吗?
如果这是正确的方法,为什么它不起作用?如果不是,正确的方法是什么?
如果我使用 init.d celeryd 守护进程脚本而不是 Supervisor,则会出现CELERY_CREATE_DIRS设置将自动创建用户/组拥有的 pid 和日志目录。在使用 Supervisord 时有没有办法复制此设置?
一方面,我知道 Supervisor 只能在前台进程中使用,但这个脚本并非如此。另一方面,我在这里看到过其他问题,似乎暗示您应该能够从 Supervisor 运行 shell 脚本。
感谢您的帮助。
# celery-supervisor-setup
#!/bin/bash
for i in 1 2 3
do
if [ -f "/var/log/celery/worker${i}.log" ]; then
echo "processing $i"
chown celery:celery /var/log/celery/worker${i}.log
fi
done
if [ ! -d "/run/celery" ]; then
mkdir /run/celery
chown celery:celery /run/celery
fi
# /etc/supervisor/conf.d/supervisor.conf
[program:celery-setup]
command = /www/myproj/conf/celery-supervisor-setup
; This next command didn't work
;command = bash -c " /www/myproj/conf/celery-supervisor-setup"
user = root
stdout_logfile = /var/log/celery_setup_stdout.log
stderr_logfile = /var/log/celery_setup_stderr.log
redirect_stderr = true
autostart = true
autorestart = false
priority=997
[program:celeryw1]
command=/home/myproj/venv/myproj/bin/celery worker --app=conf.celeryapp:app -n worker1 --config=celeryconfig -Q default --loglevel=info --pidfile=/var/run/celery/worker1.pid
directory=/www/myproj
user=celery
numprocs=1
stdout_logfile=/var/log/celery/worker1.log
stderr_logfile=/var/log/celery/worker1.log
redirect_stderr=true
autostart=true
autorestart=true
startsecs=1
stopwaitsecs=600
killasgroup=true
priority=998
; Note that I have "celeryw2" and "celeryw3" subprocess groups that are similar
; to the above except they refer to workers 2 and 3. I omitted them to save space.
[group:celery-workers]
programs=celeryw1,celeryw2,celeryw3
priority=999