Magento 1.9.1 cron_schedule nie jest wybierany na zawsze

Spędziłem prawie 3 dni i nie mogę zrozumieć i zmusić Magento Cron do przetworzenia zaplanowanych zadań. Korzystam z Magento 1.9.1.0 i ostatnio zauważyłem, że e-maile z zamówieniami są teraz w kolejce zamiast natychmiastowego wysyłania. Rozumiem konieczność, ale nie mogę zmusić systemu do wybierania kolejek.

Oto moje spojrzenie na Cronjob.

Oto moja linia poleceń cronjob.

Oto jak tworzone są zadania w tabeli cron_schedule.

Ponieważ rekordy są tworzone w tabeli cron_schedule, myślę, że Cron działa raz na 5 minut. Jeśli ręcznie usunę te rekordy za pomocą PhpMyAdmin, rekordy zostaną utworzone automatycznie po pewnym czasie.

Ale status zadań pozostaje „w toku” i nigdy nie został ukończony. Nie jestem pewien, czy coś jest nie tak z moją konfiguracją, czy coś mi brakuje. Czy ktoś może mi pomóc, jak zaplanować uruchomienie zaplanowanego zadania na czas. Także dlaczego utworzono wiele rekordów dla jednego kodu zadania?

Aktualizacja

Wyczyściłem cały stół, a cron utworzył zaplanowane zadania. Wszystkie zadania są w stanie oczekiwania i nigdy nie są uruchamiane, nawet czekając dłużej niż 60 minut. Coś jest nie tak w Magento 1.9.1

Aktualizacja 11/02: Dzisiaj zrobiłem trochę więcej analizy tego procesu.

Edytowałem cron.php jak poniżej

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';

Edytowałem klasę Mage_Cron_Model_Observer jak poniżej

public function dispatch($observer) {
  echo 'iam inside dispath';

Zrozumiałem, że kiedy cron uruchamia -mdefault, powinien wywołać funkcję dispatch i nastąpi wykonanie. Ale to, co się stało, było jak poniżej w wynikach crona.

Content-type: text/html

iam before mdefault 1iam before malways 1i returned success

Oznacza to, że wysyłka nie jest wywoływana w ogóle ...

Spróbujcie jeden inny

Ręcznie zmieniłem zmienną $isShellDisabled = true;i zmieniłem poniżej w cron.php.

if ($isShellDisabled) {
  echo 'before always';
  Mage::dispatchEvent('always');
  echo 'after always';
  Mage::dispatchEvent('default');
  echo 'after default';
} else {
  Mage::dispatchEvent($cronMode);
}

Wyjście crona dla powyższego jest jak poniżej

Content-type: text/html

before alwaysiam inside dispath alwaysafter always

Teraz nazywa się „dispatchAlways”, ale nie „dispatch”

Żadna z odpowiedzi mi nie pomaga. Nigdy nie wybiera zaplanowanych zadań. To znaczy, kiedy Cron uruchamia się po raz pierwszy, pomyślnie utworzył zadania w tabeli. Ale nigdy nie wykonuje zadania.

To była wersja Cron Jobs w PHP.

Wersja PHP została poprawnie ustawiona dla strony, dlatego działała; jednak Cron Jobs działał na macierzystym serwerze PHP 5.3 i dlatego błędy pojawiały się tylko podczas uruchamiania Crona. Zaktualizowałem do wersji 5.5.

Zmieniono polecenie Crona:

php /home/mydomainname/public_html/cron.php
to
php55 /home/mydomainname/public_html/cron.php

lub w hostgatorze:

/opt/php55/bin/php /home/mydomainname/public_html/cron.php

w cron.php

$isShellDisabled = (stripos(PHP_OS, 'win') === false) ? $isShellDisabled : true;

Po tym wierszu dodaj:

$isShellDisabled = true;

próbowałeś opróżnić cron_schedulestół? Sprawdź, czy po około godzinie zapełniają się nowe zadania.

Możesz także użyć Aoe_Scheduler, aby wyłączyć określone cronjobs. Sprawdź, czy któryś z nich może spowodować błąd, który zatrzymuje wszystkie pozostałe zadania.

Sposób, w jaki cronjobs Magento są ustawione na błąd krytyczny w skrypcie, spowoduje niepowodzenie wykonania wszystkich zadań

Na początek sugeruję przywrócenie twoich ustawień z powrotem do domyślnych ustawień crona Magento:

Występuje problem z twoimi bieżącymi ustawieniami: twój harmonogram jest generowany co 15 minut, ale zaplanowany tylko na 5 minut, co pozostawia 10-minutową przerwę.

Ten sam problem dla mnie.

Znaleziono błąd „Za późno ...”.

Po wyczyszczeniu cron_scheduletabeli cron.sh przestał działać (już nie planuje).

Działa dopiero po zabiciu wszystkich starych procesów Crona.

Miałem ten sam problem. Mój problem dotyczył strefy czasowej: kolumny created_ati scheduled_atw cron_scheduletabeli powinny być UTC + 0, moje wpisy to UTC + 2.

Aby to sprawdzić, można po prostu ustawić daty od created_ati scheduled_atdo wczoraj i czekać aż do następnego harmonogramu cron.

Mam nadzieję, że komuś pomoże!

Na Bluehost, w pliku cron.sh zmień

 PHP_BIN=`which php`

do

 PHP_BIN="php54s"

Domyślnie na hostingu współdzielonym działa PHP 5.2.

Musiałem także zmienić cron.php, zastępując dwie $isShellDisabledlinie $isShellDisabled = true;

Aby pozbyć się ostrzeżeń PHP, wcześniej dodałem te wiersze

$_SERVER['SCRIPT_NAME'] = 

if (empty($_SERVER['SCRIPT_FILENAME'])) $_SERVER['SCRIPT_FILENAME'] = '~/public_html/cron.php';
if (empty($_SERVER['SCRIPT_NAME'])) $_SERVER['SCRIPT_NAME'] = '/cron.php';