Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Laravel 5: Job schedule without overlap

I am trying to schedule a laravel job every minute without overlap, following the docs: http://laravel.com/docs/5.0/artisan

When I run $schedule->call('Cron::myjob'); it works great, and fires every minute,

When I try to modify it so it never overlaps: $schedule->call('Cron::myjob')->name('job-name')->withoutOverlapping(); it fires once and never again.

What am I doing wrong? My command is using "return" to send the action back to the job, so it should know that it is completed.

EDIT: I found the issue. It seems the first time I ran the command I didnt "return" the action, so it never ran the command again. I chose a new job name and ran the command again and everything is working

like image 263
Jay Avatar asked Jun 01 '15 14:06

Jay


1 Answers

In order to prevent overlapping Laravel uses files named "schedule-xxxxxx" where xxxxxx is a hash of the command that shouldn't overlap with itself. The files are placed in storage/framework. If something goes wrong while the command is executing, the file might not be deleted resulting in the command failing to run again.

What OP did - renaming the command - is one workaround. A little simpler one is deleting the mutex files:

rm storage/framework/schedule-*

But neither of these is a real solution, unless you're 100% sure the command will always run correctly from now on. Otherwise the problem might repeat soon.

I ended up putting something like this in my cron file:

find /var/www/storage/framework/ -name schedule-5b904de82f094302106f83418c5adb01 -mmin +20 | xargs -I{} rm {}

I expect the command to take less than a minute to run. It's scheduled to run every 5 minutes. So if its mutex file is older than 20 minutes, I assume something went wrong this time and the command should be allowed to run again.

It's also far from perfect because it's separate from the command it tries to protect and therefore easy to forget if the command gets renamed or the entire application gets moved somewhere. It also doesn't protect against the situation where the mutex file wasn't deleted because the command actually is running, only something went wrong and it takes much more time than usually. In such a case overlapping will be allowed and everything might blow up. But it solves my problem, at least for now.

like image 128
Rafał G. Avatar answered Sep 30 '22 01:09

Rafał G.