I want this command php artisan queue:work stays active and not get killed for a long time...
when we have queues, and we run the server, if we only use the command php artisan queue:work, it can get killed for some reason and our queues don't work anymore. what should I do in this case?
Your question is quite ambiguous , but I'll assume that you need the command to run whilst accessing that same instance of command line without closing or stopping the process.
I would recommend using Screens for this which allow you to effectively have virtual terminals open within the one you have.
Give the following article a read
https://www.digitalocean.com/community/tutorials/how-to-install-and-use-screen-on-an-ubuntu-cloud-server
Related
I want to make an uptime control application with Laravel.
New sites will be added to the database constantly.
Each site will be thoroughly checked. Whether the site is online or not, when was it interrupted, how long did it take to go online, etc. I will store such details in the database.
No problem so far, I can do these. I wanted to explain these parts to explain better.
However, I am stuck on how to make a background service through laravel.
For example, if I were doing this with plain php, I would create a service for linux and run it with "systemctl start foo", with the command "systemctl enable foo" I would always make it run. I would create a php file and it could run forever in a "while" loop. or I could use nohup or supervisor.
But I don't want to go this way. This is a framework and I want to move forward in that direction.
I did a lot of research but couldn't find a solution. There is a laravel queue way for some operations, but that's not exactly what I want. For this to work, we add it to the queue with the "dispatch" method and run the processes in the queue with the "php artisan queue:work" command. We use supervisor for continuous operation.
But in my case there is no "dispatch" trigger. There is a constant listening to the database and running a transaction.
I created a command with "php artisan make:command foo" and I run a command with "php artisan foo" it works ok.
But how can I run it continuously, is there a way around this? Should I go outside the framework?
If I can resolve this issue without leaving the framework, is there a way to monitor them on the frontend? (websocket etc. external)
Because I plan to run other services in the background and it would be great to be able to view their current status, uptime, network usage and output.
Or a small idea that comes to my mind, I will start the first process manually (I will manually add it to the queue via dispatch and run the queue on the supervisor side). When the first transaction is completed, it will send the next site to Jobs via dispatch. but it doesn't seem like a very healthy way.
I preferred to proceed using supervisor.
I used a configuration like this:
[program:your-progam-name]
process_name=%(program_name)s_%(process_num)02d
command=php /home/foo/bar/baz/laravel_path/artisan yourProgramCommandCode
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
user=paparazi
redirect_stderr=true
stdout_logfile=/home/foo/bar/baz/laravel_path/logs/visor.log
stopwaitsecs=3600
details: https://laravel.com/docs/9.x/queues#configuring-supervisor
I send mail as a cron job with Laravel. For this, when I want to use the last value I added in my resources/lang/de.json file in the mail blade template file(resources/views/mails/...blade.php), it gives an output as if such a value is not defined. However, if I use the same key in a blade file I created before, it works without any errors. In addition, the keys that I added to the same file (de.json) in the first time work without errors in the same mail blade file.
Thinking it's some kind of cache situation, I researched and found out that restarting the queue worker might fix the problem. However, both locally and on the server with ssh.
'php artisan queue:restart'
Even though I ran the command, there was no improvement.
Do you have any ideas?
Since queue workers are long-lived processes, they will not notice changes to your code without being restarted. So, the simplest way to deploy an application using queue workers is to restart the workers during your deployment process. https://laravel.com/docs/9.x/queues#queue-workers-and-deployment
but php artisan queue:restart will instruct all queue workers to gracefully exit after they finish processing their current job so that no existing jobs are lost. And I see a lot of issues with this command not to solve restart and deploy the worker.
So, Simplest way,
try to stop the worker manually (ctrl+C)
start the worker again with php artisan queue:work again.
might this help.
I'm really struggling with this issue, which is a little frustrating to me because it seems to be so simple in a Linux server. I have a Windows Azure Web App and I want to run "php artisan queue:listen" on the server continuously to take care of dispatched jobs. From what I read from the documentation, in Linux you just use Supervisor to run the command constantly and to revive it, in case it dies. From what I found online, Azure has a similar functionality called WebJobs where you can serve them a script to be ran and then decide whether it should run on a schedule or continuously (kinda like the Scheduler in Laravel). With this I have 2 questions.
1 - Is this the right solution? Place a script to run the command on a WebJob and have the WebJob run continuously?
2 - I'm not experienced in writing php scripts to run command lines, so all I can do is something like this:
echo shell_exec('php artisan queue:work');
Problem is this does not give me the output of the command (I don't see anything like the "processed" result that I see when I run the command by hand on my command console and a job is processed). It is important to me to be able to read the output of the command, because I want to be able to check the logs for errors in case something happens when a job isn't able to be processed. From the documentation shell_exec returns null in case an error is thrown so I'm completely clueless on how to deal with this.
Thank you so much in advance!
Instead of using shell_exec() you can directly upload .cmd file which includes your command php artisan queue:work, and then you can find the output log in WebJob Details page.
About how to do that, please check Ernesto's answer out.
For Azure you can make a new webjob to your web app, and upload a .cmd
file including a command like this.
php %HOME%\site\wwwroot\artisan queue:work --daemon
and defining that as a triguered and 0 * * * * * frecuency cron.
that way work for me.
For more information, please refer to Run Background tasks with WebJobs.
I am trying to run queued jobs, and pass additional parameters through the command line. My use case is this:
I have 4 running queue:work processes through supervisor. The jobs in my queue all require access to a proxy server, through which i can only have 4 processes running at any given time. When I start up a queued job, I have to find a process number (1 through 4) that is not currently being used, then run my command through that process.
I have been using a database table to store the processes and it has a column for in_use which keeps track of whether its being used, but the problem I'm seeing is when two queue:work commands run simultaneously, the same proxy process can be picked from the database for both.
What I want
php artisan queue:work --process=1
Then to somehow retrieve that argument inside the job, so I can run my 4 processes each in supervisor separately.
As a workaround, I have created a custom artisan command which will take the argument, but I then lose the queue functionality. I don't want to have to develop a custom queue process.
Is there a way to pass this argument? Or, alternatively, is there a way that I could pop jobs off the queue from within my custom artisan command, and then run them manually rather than through queue:work?
The problem could be solved by using dedicated queue's. So each queue has a specific proxy process attached to it. The only thing left is to create a function/process to determine to which queue the process should go.
https://laravel.com/docs/5.1/queues#pushing-jobs-onto-the-queue
Check out the part: Specifying The Queue For A Job
I'm pretty new to the whole Queue'd jobs thing in Laravel 4. I have some process heavy tasks I need the site to run in the background after being fired by the user doing a particular action.
When I was doing the local development for my site I was using this:
Queue::push('JobClass', array('somedata' => $dataToBeSent));
And I was using the local "sync" driver to do it. (The jobs would just automatically fire, impacting on the user experience but I assumed when going into the production phase I could switch it to beanstalkd and they would then be run in the background)
Which brings me to where I'm at now. I have beanstalkd set up with the dependencies installed with composer and the beanstalkd process listening for new jobs. I installed a beanstalk admin interface and can see my jobs going into the queue, but I have no idea how to actually get them to run!
Any help would be apprieciated, thanks!
This is actually a really badly documented feature in Laravel.
What you actually need to do is have the JobClass.php in a folder that is auto-loaded, I use app/commands, but they can also be in app/controllers or app/models if you like. And this function needs to have a fire event that takes the $job and $data argument.
To run these, simply execute php artisan queue:listen --timeout=60 in your terminal, and it will be busy emptying the queue, until it's empty, or it's been running for longer then 60 seconds. (Small note: The timeout is the time-limit to start a queue, so it may run for 69 seconds if 1 job takes 10 seconds.
If you only want to run 1 job (perfect for testing), run php artisan queue:work
There are tools like Supervisord that make sure your job handlers keep running, but I recommend to just make a Cron task that starts every X minutes based on how fast the data needs to be processed, and on how much data comes in.
Keep in mind you need to path your artisan.
php /some/path/to/artisan queue:work