2016-12-09 4 views
1

У меня есть запланированная работа Laravel, которая определена в Kernel.php как такLaravel неперекрывающееся запланированного задания не выполняются

$schedule->call('\App\Http\Controllers\[email protected]') 
    ->everyFiveMinutes() 
    ->name('process_queued_messages') 
    ->withoutOverlapping(); 

В процессе развития, моя работа бросила исключение из-за синтаксическую ошибку. Я исправил ошибку и попытался выполнить ее снова; но по какой-то причине этого не произойдет.

Я попробовал artisan down, а затем artisan up. Я также попытался перезапустить экземпляр сервера. Но ничего не помогло бы. Работа просто не выполнялась (тоже не было исключения).

Я понимаю, что проблема связана с ->withoutOverlapping(). Так или иначе, планировщик Laravel считает, что работа уже запущена и, следовательно, не выполняет ее снова.

ответ

3

Я нашел решение, посмотрев код поставщика.

Illuminate\Console\Scheduling\CallbackEvent.php 

Он создает файл в локальном хранилище с именем 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); 
} 

Удаление файла schedule-* в storage/framework решен вопрос.

3

Даже я столкнулся с этой проблемой, для этого не существует правильного решения, но обходное решение решит проблему.

Перейти к хранилищу/структуре Папка вашего проекта и удалить все файлы schedule-***********.

И снова попробуйте запустить cron. Это будет даже если вы используете withoutOverlapping() function.

Надеюсь, что это сработает для вас. Спросите, есть ли какие-либо сомнения.

+0

Я уже ответил на свой вопрос точно таким же решением. Спасибо хоть. – linuxartisan

+0

ohhh, sry .. На самом деле я был так рад поделиться своим решением этой проблемы, что я даже не прочитал другого ответа. –

0

Это случилось с нами на этой неделе, и мы думаем, что выяснили причину. Наши кроны убегают от одной из наших каталогов сайта нашего производственного сервера. Наш процесс развертывания включает в себя наличие второй папки, в которой мы развертываем/создаем, а затем выполняем обмен горячей папкой в ​​конце. Так как withoutOverlapping(), вероятно, должен обновить строку в файлах schedule- *, когда процесс будет завершен, папка может быть заменена средним заданием, и cron не сможет успешно пометить задание как выполненное в правильном файле расписания * , поэтому он думает, что он все еще работает/застревает.

Это было редкое событие, но мы добавим команду для очистки этих файлов после развертывания, чтобы это не повторилось.