Laravel 5：没有重叠的作业时间表
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/30576261/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Laravel 5: Job schedule without overlap
提问by Jay
I am trying to schedule a laravel job every minute without overlap, following the docs: http://laravel.com/docs/5.0/artisan
我正在尝试按照文档每分钟安排一次 laravel 工作而不会重叠：http://laravel.com/docs/5.0/artisan
When I run $schedule->call('Cron::myjob');it works great, and fires every minute,
当我运行$schedule->call('Cron::myjob');它时效果很好，并且每分钟都触发一次，
When I try to modify it so it never overlaps: $schedule->call('Cron::myjob')->name('job-name')->withoutOverlapping();it fires once and never again.
当我尝试修改它以使其永远不会重叠时：$schedule->call('Cron::myjob')->name('job-name')->withoutOverlapping();它会触发一次，永远不会再触发。
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
编辑：我发现了这个问题。似乎我第一次运行命令时我没有“返回”操作，所以它再也没有运行命令。我选择了一个新的工作名称并再次运行命令，一切正常
回答by Rafa? G.
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.
为了防止重叠 Laravel 使用命名为"schedule-xxxxxx"xxxxxx 的文件，其中 xxxxxx 是不应与自身重叠的命令的哈希值。文件放在storage/framework. 如果在执行命令时出现问题，文件可能不会被删除，从而导致命令无法再次运行。
What OP did - renaming the command - is one workaround. A little simpler one is deleting the mutex files:
OP 所做的 - 重命名命令 - 是一种解决方法。更简单的一个是删除互斥文件：
rm storage/framework/schedule-*
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.
但这些都不是真正的解决方案，除非您 100% 确定该命令从现在开始将始终正确运行。否则问题可能很快会重复。
I ended up putting something like this in my cron file:
我最终在我的 cron 文件中放入了这样的内容：
find /var/www/storage/framework/ -name schedule-5b904de82f094302106f83418c5adb01 -mmin +20 | xargs -I{} rm {}
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.
我希望该命令的运行时间不到一分钟。它计划每 5 分钟运行一次。因此，如果它的互斥锁文件超过 20 分钟，我认为这次出了点问题，应该允许再次运行该命令。
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 isrunning, 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.
它也远非完美，因为它与它试图保护的命令分开，因此如果命令被重命名或整个应用程序被移动到某个地方，很容易忘记。它也不能防止互斥文件没有被删除的情况，因为命令实际上正在运行，只是出了点问题，而且比平时花费的时间要长得多。在这种情况下，将允许重叠，一切都可能会爆炸。但它解决了我的问题，至少现在是这样。
