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

Laravel queue:restart is not killing workers

提问by Mark Salmon

I have a laravel 5.4 app deployed via envoyer to a non-forge server. I am running queue workers on the database driver, using supervisor to monitor, setup as described in the docs;

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

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

and using the envoyer deployment hook

并使用 envoyer 部署挂钩

cd ~/app/current
php artisan queue:restart

Problem is, after each deployment the queue workers are not restarted, the old ones continue to run and then throw errors because they are working on previous releases of the code. Running queue:restart manually from the CLI doesn't work either.

问题是，在每次部署后，队列工作人员没有重新启动，旧的工作人员继续运行，然后抛出错误，因为他们正在处理以前版本的代码。运行队列：从 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$

If I find and kill the 8 running processes manually, supervisor does restart them correctly and my queued jobs work again.

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

Can anybody think of anything that might be preventing these workers from being killed? There is nothing relevant in storage/logs/laravel.log

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

回答by Amitesh

Its important to understant few points related to following queue:restart command

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

php artisan queue:restart

• This command will instruct all queue workers to gracefully "die" after they finish processing their current job so that no existing jobs are lost.
• The queue uses the cache to store restart signals, so you should verify a cache driver is properly configured for your application before using this feature.
• Since the queue workers will die when the queue:restart command is executed, you should be running a process manager such as Supervisor to automatically restart the queue workers.

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

Which means queue:restart will not immediately restart the queue but simply 'Broadcasting queue restart signal' for queue worker to get it die, once it finished the current assigned task.

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

Ref : https://laravel.com/docs/5.6/queues#queue-workers-and-deployment

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

回答by jeff-h

In my case also, php artisan queue:restartdid nothing. The queue workers' age confirmed that they were not restarting in response to that. The following will show you when your workers launched. Mine were all different, by several days.

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

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

As part of my deployment script (gitlab, in my case) I am running php artisan queue:restart, so the queue workers restart after any code is pushed live.

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

As mentioned in a previous answer, the queue:restartcommand saves to the Laravel cache. I am using the 'file' cache driver, so cache entries are on disk at storage/framework/cache/databy default.

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

It turned out that my deploy script was running php artisan queue:restartas the gitlab-runneruser, and thus any cache entries it created were also owned by that user.

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

Running the following instantly fixed my problem. The queue workers restarted the moment this was run:

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

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

After this, commandline invocations of php artisan queue:restartwork perfectly.

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

The long-term fix was to ensure my deploy script ran php artisan queue:restartas the proper user (or chown's the cache files as needed).

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

tldr; if using the 'file' cache driver, your web server user needs to be able to read/write the cache entry created by the php artisan queue:restartcommand. Check your permissions!

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