Does Supervisord process need restart after changes to Laravel file?

Question

I am using Supervisord to monitor a queue in Laravel 4.2. This is my Supervisord config file:

[program:webhooks]
command=php artisan queue:work --daemon --queue=webhooks --tries=3 --sleep=5
directory=/var/www/html/app
stdout_logfile=/var/www/html/app/app/storage/logs/webhooks_supervisord.log
redirect_stderr=true
autostart=true
autorestart=true

As I see in the Laravel docs:

Daemon queue workers do not restart the framework before processing each job.

From what I can tell, this means that if I make a change to one of the files in the framework, that change will not be reflected in the daemon processing the queue. For example, if one of my file says echo 1; and I change to echo 2;, the version of the framework that the queue is using will still say echo 1, until I restart the queue. To have these new changes take effect, I need to run:

sudo supervisorctl
supervisor> stop webhooks
supervisor> start webhooks

Am I correct that this is required? Or is there another way to handle this so that new changes to the files will be picked up without restarting the queue?

Answer 1

You dont need to! Just do the following and the supervisor will automatically restart with fresh code.

$> CD /your/project/folder
$> php artisan queue:restart

The reason is that the artisan command will stop the queue and supervisor will force a restart again as you have set autorestart=true in the config.

To confirm, just do the following and see the uptime in the output:

$> sudo supervisorctl status

--

Additionally can do the following if you have made changes to the supervisord program's config:

$> sudo supervisorctl update

This will reload configs, add/remove as necessary, and will restart affected supervisor programs

Answer 2

Since the daemon queue worker loads the file only once it has to be restarted before any code changes are picked up. Here is a good example on how to manage multiple related queues workers once the project gets too big to manually restart every worker.

Alternatively you could use queue listener via php artisan queue:listen. This option comes at a significant increase in CPU load due to the fact that the entire framework is bootstrapped from scratch after every job.