Я провел почти 3 дня и не мог понять и заставить Magento Cron обрабатывать запланированные задания. Я использую Magento 1.9.1.0 и недавно заметил, что электронные письма с заказами теперь ставятся в очередь, а не отправляются мгновенно. Я понимаю необходимость, но не могу заставить систему выбирать очереди.
Вот мой взгляд на Cronjob.
Вот моя командная строка cronjob.
Вот как задачи создаются в таблице cron_schedule.
Поскольку записи создаются в таблице cron_schedule, я думаю, что Cron запускается раз в 5 минут. Если я вручную удаляю эти записи через PhpMyAdmin, записи создаются автоматически через некоторое время.
Но статус задач остается «ожидающим» и никогда не завершается. Не уверен, что что-то не так в моей конфигурации или я что-то упустил. Может кто-нибудь, пожалуйста, помогите мне, как заставить запланированное задание выполняться вовремя. Кроме того, почему несколько записей создаются для одного кода работы?
Обновить
Я очистил всю таблицу, и cron создал запланированные задания. Все задания находятся в состоянии ожидания и никогда не выполняются даже в ожидании более 60 минут. Что-то не так в Magento 1.9.1
Обновление 11/02: сегодня я сделал еще один анализ процесса.
Я редактировал cron.php как показано ниже
echo 'iam before mdefault 1';
shell_exec("/bin/sh $baseDir/cron.sh $fileName -mdefault 1 > /dev/null 2>&1 &");
echo 'iam before malways 1';
shell_exec("/bin/sh $baseDir/cron.sh $fileName -malways 1 > /dev/null 2>&1 &");
echo 'i returned success';
Я отредактировал класс Mage_Cron_Model_Observer, как показано ниже
public function dispatch($observer) {
echo 'iam inside dispath';
Насколько я понимаю, когда cron запускает -mdefault, он должен вызвать функцию отправки, и произойдет выполнение. Но то, что произошло, было как показано ниже в выводе cron.
Content-type: text/html
iam before mdefault 1iam before malways 1i returned success
Это означает, что отправка не называется atall ...
Друг друга попробовать
Я вручную изменил переменную, $isShellDisabled = true;
и я изменил ниже в cron.php.
if ($isShellDisabled) {
echo 'before always';
Mage::dispatchEvent('always');
echo 'after always';
Mage::dispatchEvent('default');
echo 'after default';
} else {
Mage::dispatchEvent($cronMode);
}
Выход cron для вышеупомянутого как ниже
Content-type: text/html
before alwaysiam inside dispath alwaysafter always
Теперь он вызывает «dispatchAlways», но не «диспетчеризация»
Ни один из ответов не помогает мне. Он никогда не выбирает запланированные задачи. Т.е. когда Cron запускается впервые, он успешно создал задачи в таблице. Но это никогда не выполняет задачу.
источник
*/5 * * * * /bin/sh PATH_TO_PRODUCTION/cron.sh
если есть.cron_schedule
стол? Проверьте, не заполнилось ли оно новыми задачами через час или около тогоОтветы:
Это была PHP-версия Cron Jobs.
Версия PHP была правильно установлена для сайта, поэтому он работал; однако Cron Jobs работал на сервере PHP 5.3, поэтому я получал ошибки только при запуске Cron. Я обновился до версии 5.5.
Изменена команда Cron:
или в hostgator:
в cron.php
После этой строки добавьте:
источник
php -v
в терминале, чтобы увидеть, какую версию PHP использует терминал. В моем случае это было 5,6. Поэтому я должен был заставить использование PHP 7.0, изменивphp
наea-php70
вcrontab -e
. Благодарность!ты пытался очистить
cron_schedule
стол? Проверьте, заполнено ли оно новыми задачами через час или около того.Также вы можете использовать Aoe_Scheduler для отключения определенных cronjobs. Посмотрите, может ли какой-то конкретный из них вызвать ошибку, которая останавливает все другие задачи.
То, как Magento cronjobs устанавливают фатальную ошибку в скрипте, приведет к сбою при выполнении всех задач
источник
В качестве первого шага я бы предложил вернуться к настройкам cron Magento по умолчанию:
Существует проблема с вашими текущими настройками: ваше расписание генерируется каждые 15 минут, но запланировано только на 5 минут, что оставляет 10-минутный промежуток.
источник
$isShellDisabled = true;
и когда я запускаю Cron.php через браузер, задания выбираются, но не через CronTab.php -f cron.php
и./cron.sh
посмотрите, произведут ли они что-нибудь для дальнейшего изучения.Та же проблема для меня.
Ошибка "Слишком поздно ...".
После очистки
cron_schedule
таблицы cron.sh перестал работать (больше не планировал).Работал только после уничтожения всех старых процессов Cron.
источник
У меня такая же проблема. Мой вопрос был часовой пояс конкретным:
created_at
иscheduled_at
столбцы вcron_schedule
таблице должна быть UTC + 0, мои записи были UTC + 2.Чтобы убедиться в этом, вы можете просто установить даты от
created_at
иscheduled_at
до вчера и дождаться следующего расписания cron.Надеюсь, что это помогает кому-то!
источник
На Bluehost, в cron.sh меняются
в
По умолчанию на виртуальном хостинге работает PHP 5.2.
Я также должен был изменить
cron.php
, заменив две$isShellDisabled
строки$isShellDisabled = true;
Чтобы избавиться от предупреждений PHP, я также добавил эти строки перед
источник