On the Laravel Horizon dashboard, some job always shows as "paused":
How can I prevent this issue?
I had the same issue. It seemed to work and suddenly jobs would pause for no reason. I was using two applications with the same redis server, so conflicts would occur occasionally.
To resolve this you need to modify config/database.php and change the value of the key redis.default.database so the two (or more) applications don't mix up their keys.
Related
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.
so while deploying into one test env (which has 2 instances of the server/API running), I started to receive ActiveRecord::ConcurrentMigrationError, after some digging I realize that my 2 instances run migrations separate and that causes the issue, after receiving this error no migrations are applied at all.
Checked using: rake db:migrate:status
I looked into the platform, and I found some info related to this error but I don't think are the proper solution, because the solution is to deactivate the lock introduced in rails 5 which can cause some weird issues during migrations (maybe I missed something if so, please let me know 👌).
Solution found
So the question:
Is there any way to solve this issue without deactivating the lock, or is that the proper solution (apart from only leave one of the instance instead of the 2 run the migration)?
Note: I would like to keep my migrations running automatically in both instances (just after the release) as usual.
Thx in advance 👍.
I have two apps running on the same server.
Now it seems like when adding withoutOverlapping() to the scheduler job and managing the base cronjob via cron itself, these 2 apps are blocking each other in execution.
Could that be?
Yes, withoutOverlapping only works per application.
Laravel creates a file in the storage folder with a hash of the job. This way, if the file exists, Laravel knows the job is still running. The one application cannot possibly know if the other one is currently running a job because it does not have access to the storage folder of the other application.
If your code looks like the following
$schedule->command('process:queue 0')->everyMinute()->withoutOverlapping();
$schedule->command('process:queue 1')->everyMinute()->withoutOverlapping();
It is because same commands with different parameters might bc considered overlapping.
I.e. the hash of the job will consider only the command signature.
I have a Laravel Scheduled job which is defined in Kernel.php like so
$schedule->call('\App\Http\Controllers\ScheduleController#processQueuedMessages')
->everyFiveMinutes()
->name('process_queued_messages')
->withoutOverlapping();
During development, my job threw an exception due to a syntax error. I corrected the error and tried executing it again; but for some reason it won't.
I tried artisan down and then artisan up. I also tried restarting the server instance. But nothing would help. The job just didn't get executed (there was no exception either).
I realize that the problem is due to ->withoutOverlapping(). Somehow, Laravel scheduler is thinking that the job is already running and hence is not executing it again.
I found the solution by looking at the vendor code.
Illuminate\Console\Scheduling\CallbackEvent.php
It creates a file in local storage with the name schedule-*.
public function withoutOverlapping()
{
if ( ! isset($this->description))
{
throw new LogicException(
"A scheduled event name is required to prevent overlapping. Use the 'name' method before 'withoutOverlapping'."
);
}
return $this->skip(function()
{
return file_exists($this->mutexPath());
});
}
protected function mutexPath()
{
return storage_path().'/framework/schedule-'.md5($this->description);
}
Deleting the file schedule-* at storage/framework resolved the issue.
To anyone reading this, deleting the schedule files yourself, is not the right way to go. You need to specify - the lock time - based on which, withoutOverlapping prevents further tasks from running.
As cited in Laravel - Task Scheduling
If needed, you may specify how many minutes must pass before the "without overlapping" lock expires. By default, the lock will expire after 24 hours:
Your problem originates due to the fact that withoutOverlapping applies a default lock for 24 hours. So you had to wait for 24 hours before similar tasks are accepted. Simply adjust the lock time based on your needs by doing:
$schedule->command('emails:send')->withoutOverlapping(10); // where 10 refers to minutes
This did the trick for me:
php artisan cache:clear
I had this problem too. There's not a proper solution for this but a workaround will solve the issue.
Go to storage/framework Folder of your project and delete all the schedule-*********** files.
And then again try to run the cron. It will even if you use withoutOverlapping() function.
Hope this works for you. Ask if any doubt.
Since laravel 8.x you can use specific command to clear mutex files, for example if task stucks because of a server reboot while task were executing
the problem of clear:cache is that this command clear cache for the entire application and this command just clears mutex-files
php artisan schedule:clear-cache
This happened to us this week and we think we figured out the cause. Our crons run off one of our production server's site folder. Our deploy process involves having a second folder where we do deploy/build, and then do a hot folder swap at the end. Since withoutOverlapping() likely has to update a line in the schedule-* files when the process is done, the folder might be swapped mid job and the cron is unable to successfully mark the job as having been finished in the correct schedule-* file, so it thinks it's still running/stuck.
It was a rare occurrence but we're going to add a command to clear out these files after a deploy so it doesn't happen again.
I have a Laravel 3 project, running on a plesk 11.5 CentOS 4(dedicated). It used to be on an IIS server, but i had to migrate it to plesk, since the company i'm working for is dumping the IIS server. Everything seemed to be running smoothly, until i logged out from my application, at first i got a WSOD (white screen of death), then i enabled php error reporting, and this is the error that was displayed:
Fatal error: Cannot override final method Laravel\Database\Eloquent\Model::sync()
This is a very strange error, since i have no method called Sync in any of my classes, and needless to say that there was no such error while the project was running on IIS.
I tried several different combinations of session/cache drivers, the only one that seems to be working is the APC driver.
When i have the APC driver enabled for cache and session, the above Fatal error is not displayed and everything works correctly. The PROBLEM is that i have given the Session Lifetime a value of 60(minutes) but it is completely ignored, meaning that the user is logged out after 2 or 3 minutes.
I've been to the Laravel IRC channel with this issue, some people kindly suggested to tweak the APC memory and ttl (time to leave) settings, but with no luck unfortunately :(.
Here are some APC settings from my server configuration:
apc.gc_ttl 3600
apc.shm_size 1024M
apc.shm_strings_buffer 32M
I desperately need help if anyone has any to offer! This is for a live running project and i need to find a solution asap.
I had the exact same issue and couldn't find a solution. I was going round in circles trying to figure out what on earth was going wrong.
I finally came across this post:
Fatal error: Cannot override final method
You need to make sure that the apc.include_once_override setting is set to 0. In your apc.ini file set like so:
apc.include_once_override=0
This error seems to be caused by caching of included classes.
I solved the problem after looking around the plesk panel.
The problem was that i had "Run PHP as FastCGI application" selected.
I switched to "Run PHP as CGI application" and everything works perfectly.
I'm not sure what the exact source of the problem was, only that FastCGI triggered the error.