所以我有一个shell脚本来守护芹菜,并创build一堆作为守护进程运行的工作者。 我想有一种方法来重新启动芹菜任务时,底层源被更改,因为--autoreload
选项不起作用。
根据我对芹菜文档的阅读, kill -HUP $pid
会杀死芹菜进程,然后用相同的参数创build一个新的。 但是,当我尝试它,芹菜倒下,不回来。 我的命令有问题吗? 在开始的时候,芹菜可能会在后台默默无闻(如果是这种情况,我会在哪里弄清楚什么是错误的,并看到日志输出)?
文字命令是kill -HUP \`cat /var/run/celery/w1.pid\`
。 检查ps aux | grep celery
ps aux | grep celery
什么都没有返回。 发送kill信号后根本没有日志文件输出。
有任何想法吗?
Celery中的HUP处理程序只是简单地启动closures过程,并以与完成时启动的过程相同的参数调用execv。 这是一个非常天真的方式,因为它不知道它是否会回来,但我们还没有find一个更好的解决scheme,在信号处理程序中工作。
如果你使用celery multi
那么最好使用celery multi restart
命令,它也会等待老工人先停下来(generic-init.d脚本将它用于重启命令)。
这里是SIGHUP处理程序代码: https : //github.com/celery/celery/blob/master/celery/apps/worker.py#L280-L295正如你可能看到这需要sys.executable
和sys.argv
设置它可以用来重新启动工人(不知道为什么这没有logging)
我不知道是谁开始了这个趋势,但是人们开始期待SIGHUP
重新读取configuration文件或者重新启动自己,但是要正确地执行并不总是那么容易,我认为selectterminal窗口发送的信号是不负责任的closures;)我们已经讨论过多次拆除Celery HUP处理程序。
您确定您正在咨询的文档是针对实际版本部署的吗? 如果HUP
function的添加版本比您使用的版本更新,则默认行为可能是终止该进程。
(我很抱歉,如果这是无益的,我没有这个特定的守护进程的经验,这是我能提供的最好的。)