Laravel 队列：重启不会杀死工作人员

Question

我有一个通过 envoyer 部署到非伪造服务器的 laravel 5.4 应用程序。我正在数据库驱动程序上运行队列工作器，使用主管进行监视，如文档中所述进行设置；

command=php /home/data/app/current/artisan queue:work --sleep=3 --tries=3

并使用 envoyer 部署挂钩

cd ~/app/current
php artisan queue:restart

问题是，在每次部署后，队列工作人员没有重新启动，旧的工作人员继续运行，然后抛出错误，因为他们正在处理以前版本的代码。运行队列：从 CLI 手动重启也不起作用。

data@medicone:~/ccpbase/current$ ps -aux | grep queue:work
data      4347  0.0  0.2 292988 34852 ?        S    11:12   0:00 php /home/data/ccpbase/current/artisan queue:work --sleep=3 --tries=3
data      4348  0.0  0.2 292988 34864 ?        S    11:12   0:00 php /home/data/ccpbase/current/artisan queue:work --sleep=3 --tries=3
data      4349  0.0  0.2 292988 34720 ?        S    11:12   0:00 php /home/data/ccpbase/current/artisan queue:work --sleep=3 --tries=3
data      4350  0.0  0.2 292988 34880 ?        S    11:12   0:00 php /home/data/ccpbase/current/artisan queue:work --sleep=3 --tries=3
data      4351  0.0  0.2 292988 34972 ?        S    11:12   0:00 php /home/data/ccpbase/current/artisan queue:work --sleep=3 --tries=3
data      4382  0.0  0.2 292988 34904 ?        S    11:12   0:00 php /home/data/ccpbase/current/artisan queue:work --sleep=3 --tries=3
data      4383  0.0  0.2 292988 34992 ?        S    11:12   0:00 php /home/data/ccpbase/current/artisan queue:work --sleep=3 --tries=3
data      4384  0.0  0.2 292988 34980 ?        S    11:12   0:00 php /home/data/ccpbase/current/artisan queue:work --sleep=3 --tries=3
data      4863  0.0  0.0  14228  1016 pts/0    S+   11:32   0:00 grep queue:work
data@medicone:~/ccpbase/current$
data@medicone:~/ccpbase/current$ php artisan queue:restart
Broadcasting queue restart signal.
data@medicone:~/ccpbase/current$ ps -aux | grep queue:work
data      4347  0.0  0.2 292988 34852 ?        S    11:12   0:00 php /home/data/ccpbase/current/artisan queue:work --sleep=3 --tries=3
data      4348  0.0  0.2 292988 34864 ?        S    11:12   0:00 php /home/data/ccpbase/current/artisan queue:work --sleep=3 --tries=3
data      4349  0.0  0.2 292988 34720 ?        S    11:12   0:00 php /home/data/ccpbase/current/artisan queue:work --sleep=3 --tries=3
data      4350  0.0  0.2 292988 34880 ?        S    11:12   0:00 php /home/data/ccpbase/current/artisan queue:work --sleep=3 --tries=3
data      4351  0.0  0.2 292988 34972 ?        S    11:12   0:00 php /home/data/ccpbase/current/artisan queue:work --sleep=3 --tries=3
data      4382  0.0  0.2 292988 34904 ?        S    11:12   0:00 php /home/data/ccpbase/current/artisan queue:work --sleep=3 --tries=3
data      4383  0.0  0.2 292988 34992 ?        S    11:12   0:00 php /home/data/ccpbase/current/artisan queue:work --sleep=3 --tries=3
data      4384  0.0  0.2 292988 34980 ?        S    11:12   0:00 php /home/data/ccpbase/current/artisan queue:work --sleep=3 --tries=3
data      4869  0.0  0.0  14228   960 pts/0    S+   11:32   0:00 grep queue:work
data@medicone:~/ccpbase/current$

如果我手动找到并终止了 8 个正在运行的进程，主管会正确地重新启动它们并且我排队的作业会再次运行。

任何人都可以想出什么可能阻止这些工人被杀害？storage/logs/laravel.log 中没有任何相关内容

Answer 1

在我的情况下，php artisan queue:restart也没有做任何事情。队列工作人员的年龄证实，他们并没有因此而重新启动。以下将显示您的工作人员何时启动。我的都不同了，几天了。

$ ps -eo pid,lstart,cmd | grep queue:work

作为我的部署脚本（在我的例子中是 gitlab）的一部分，我正在运行php artisan queue:restart，因此在任何代码被实时推送后，队列工作器会重新启动。

正如之前的回答中提到的，该queue:restart命令会保存到 Laravel 缓存中。我正在使用“文件”缓存驱动程序，因此storage/framework/cache/data默认情况下缓存条目位于磁盘上。

结果证明我的部署脚本是以用户php artisan queue:restart身份运行的gitlab-runner，因此它创建的任何缓存条目也归该用户所有。

运行以下立即解决了我的问题。队列工作人员在运行时重新启动：

sudo chown -R www-data:www-data storage/framework/cache

在此之后，命令行调用php artisan queue:restart完美地工作。

长期修复是确保我的部署脚本php artisan queue:restart以正确的用户身份运行（或者chown根据需要运行缓存文件）。

tldr; 如果使用“文件”缓存驱动程序，您的 Web 服务器用户需要能够读/写由php artisan queue:restart命令创建的缓存条目。检查您的权限！

Answer 2

了解与以下 queue:restart 命令相关的几点很重要

php artisan queue:restart

• 此命令将指示所有队列工作人员在处理完当前作业后优雅地“死亡”，以便不会丢失现有作业。
• 队列使用缓存来存储重启信号，因此在使用此功能之前，您应该验证为您的应用程序正确配置了缓存驱动程序。
• 由于在执行 queue:restart 命令时队列工作器会死亡，因此您应该运行一个进程管理器（例如 Supervisor）来自动重新启动队列工作器。

这意味着 queue:restart 不会立即重新启动队列，而是简单地“广播队列重新启动信号”，以便队列工作人员在完成当前分配的任务后使其死亡。

参考：https : //laravel.com/docs/5.6/queues#queue-workers-and-deployment