Magento 1.9.1 cron_schedule ist nicht für immer ausgewählt


12

Ich verbrachte fast 3 Tage und kann den Magento Cron nicht verstehen und veranlassen, die geplanten Aufgaben zu verarbeiten. Ich verwende Magento 1.9.1.0 und habe kürzlich festgestellt, dass Bestell-E-Mails nun in der Warteschlange stehen und nicht mehr sofort gesendet werden. Ich verstehe die Notwendigkeit, kann aber das System nicht dazu bringen, die Warteschlangen auszuwählen.

Hier ist mein Sehvermögen für Cronjob. Bildbeschreibung hier eingeben

Hier ist meine Cronjob-Befehlszeile. Bildbeschreibung hier eingeben

So werden die Aufgaben in der Tabelle cron_schedule erstellt. Bildbeschreibung hier eingeben

Da die Datensätze in der Tabelle cron_schedule erstellt werden, wird der Cron meiner Meinung nach alle 5 Minuten einmal ausgeführt. Wenn ich diese Datensätze manuell über PhpMyAdmin lösche, werden die Datensätze nach einiger Zeit automatisch erstellt.

Der Status der Aufgaben bleibt jedoch "ausstehend" und wird nie abgeschlossen. Ich bin mir nicht sicher, ob etwas in meiner Konfiguration nicht stimmt oder ich etwas vermisse. Kann mir bitte jemand helfen, wie ich die geplante Aufgabe rechtzeitig ausführen kann? Warum werden auch mehrere Datensätze für einen Jobcode erstellt?

Aktualisieren

Ich habe den gesamten Tisch abgeräumt und der Cron hat die geplanten Jobs erstellt. Alle Jobs sind im Status "Ausstehend" und werden nie ausgeführt, selbst wenn sie länger als 60 Minuten warten. In Magento 1.9.1 stimmt etwas nicht

Update 11/02: Heute habe ich den Prozess etwas genauer analysiert.

Ich habe die cron.php wie folgt bearbeitet

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

Ich habe die Mage_Cron_Model_Observer-Klasse wie folgt bearbeitet

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

Meines Wissens nach sollte der Cron, wenn er den -mdefault ausführt, die Dispatch-Funktion aufrufen und die Ausführung erfolgen. Was aber passierte war wie unten in der Cron-Ausgabe.

Content-type: text/html

iam before mdefault 1iam before malways 1i returned success

Es bedeutet, dass der Versand nicht immer aufgerufen wird ...

Einander versuchen

Ich habe die Variable manuell geändert $isShellDisabled = true;und das Folgende in der cron.php geändert.

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

Die Cron-Ausgabe für das Obige ist wie folgt

Content-type: text/html

before alwaysiam inside dispath alwaysafter always

Jetzt heißt es "dispatchAlways", aber nicht "dispatch"

Keine der Antworten hilft mir. Die geplanten Aufgaben werden nie ausgewählt. Dh wenn der Cron zum ersten Mal ausgeführt wird, wurden die Aufgaben in der Tabelle erfolgreich erstellt. Aber es führt die Aufgabe niemals aus.


Was passiert, wenn Sie cron.php über einen Webbrowser ausführen? Es wird eine leere Seite sein, aber ich meine, was passiert mit Ihren Cron-Aufgaben?
Seanbreeden

Versuchen Sie es mit dem Bash-Skript: */5 * * * * /bin/sh PATH_TO_PRODUCTION/cron.shfalls verfügbar.
Phil Birnie

@seanbreeden, wenn ich über eine URL im Browser starte, wird eine leere Seite angezeigt. Den Aufgaben ist nichts passiert. Ich habe die Frage mit den neu erstellten Aufgaben aktualisiert.
Malaiselvan

@PhilB, .sh macht keinen Unterschied. Es ist ähnlich, dass die ausstehenden Aufgaben für immer ausstehen, aber ich bin sicher, dass der Cron alle 5 Minuten ausgeführt wird.
Malaiselvan,

hast du versucht den cron_scheduletisch zu leeren Überprüfen Sie, ob nach etwa einer Stunde neue Aufgaben erledigt sind
Sander Mangel

Antworten:


3

Es war die PHP-Version von Cron Jobs.

Die PHP-Version wurde für die Site korrekt eingestellt, weshalb sie funktionierte. Cron Jobs wurde jedoch mit PHP 5.3 ausgeführt, weshalb ich die Fehler nur beim Ausführen von Cron erhalten habe. Ich habe auf Version 5.5 aktualisiert.

Geänderter Cron Befehl:

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

oder in hostgator:

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

in cron.php

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

Fügen Sie nach dieser Zeile Folgendes hinzu:

$isShellDisabled = true;

Die Erwähnung, cron.php in einer bestimmten PHP-Version (in meinem Fall ea-php70) auszuführen, behebt die Probleme, auf die ich gestoßen bin: php -vIm Terminal ausführen, um zu sehen, welche PHP-Version das Terminal verwendet. In meinem Fall war es 5.6. Also musste ich die Verwendung von PHP 7.0 erzwingen, indem ich phpzu ea-php70in wechselte crontab -e. Vielen Dank!
Daan van den Bergh

2

hast du versucht das zu leeren? cron_schedule tischÜberprüfen Sie, ob es nach etwa einer Stunde mit neuen Aufgaben voll ist.

Auch können Sie verwenden Aoe_Scheduler verwenden , um bestimmte Cronjobs zu deaktivieren. Überprüfen Sie, ob eine bestimmte Ursache einen Fehler verursacht, durch den alle anderen Aufgaben angehalten werden.

Die Art und Weise, wie Magento-Cronjobs in einem Skript als schwerwiegender Fehler eingestuft werden, führt dazu, dass die Ausführung aller Aufgaben fehlschlägt


Danke für die Antwort. Wird der schwerwiegende Fehler in einem Protokoll erfasst? Ich habe ein paar weitere Ergebnisse zu meinem Fall aktualisiert und das gleiche in meiner Frage aktualisiert.
Malaiselvan

@seanbreeden: Heute ist mir aufgefallen, dass ich die Cron.php über einen Webbrowser starte, wenn ich die Zeitpläne auswähle. Dies beweist, dass in keinem der Skripte ein schwerwiegender Fehler vorliegt. Irgendeine Idee, warum der Cron nicht über Crontab läuft?
Malaiselvan

2

Als ersten Schritt würde ich vorschlagen, Ihre Einstellungen auf die Standard-Cron-Einstellungen von Magento zurückzusetzen:

Magento Cron-Standardeinstellungen

Es gibt ein Problem mit Ihren aktuellen Einstellungen: Ihr Zeitplan wird alle 15 Minuten erstellt, aber nur für 5 Minuten im Voraus geplant, wodurch eine Lücke von 10 Minuten entsteht.


Vielen Dank. Auch nachdem ich auf den Standard zurückgesetzt habe, funktioniert es nicht. Bei der ersten Ausführung wurden alle Jobs in der Tabelle cron_schedule mit der geplanten Zeit erstellt. Die Jobs werden nie ausgewählt und bleiben für immer in der Tabelle. Eine Sache ist mir nach dem Einstellen aufgefallen $isShellDisabled = true;und wenn ich die Cron.php über den Browser starte, werden die Jobs ausgewählt, aber nicht über CronTab.
Malaiselvan

Dieses Problem ist noch nicht gelöst. Wird es ein Problem mit meinem Hosting-Provider geben? Ich sehe, dass das Skript in regelmäßigen Abständen ausgelöst wird, aber nur die Jobs werden nicht ausgewählt. Wird es auch ein Problem sein, da ich von 1.8 migriert bin?
Malaiselvan

Hat dein Cronjob genug Gedächtnis? Probieren Sie die Fehlerprotokolle aus, um festzustellen, ob sich dort etwas befindet, das helfen könnte.
Kristof bei Fooman

Dieses Problem ist noch nicht gelöst ... Jeden Tag breche ich mir den Kopf. Fehlerprotokolle? wo kann ich die sehen
Malaiselvan,

Bei Fehlerprotokollen wenden Sie sich bitte an Ihren Systemadministrator oder Webhost, da dieser den Speicherort und den Zugriff auf das Fehlerprotokoll des Servers kennen sollte. Es kann auch hilfreich sein, den Cron-Job manuell über die Befehlszeile auszuführen. Probieren Sie beide aus php -f cron.phpund ./cron.shprüfen Sie, ob sie weitere Nachforschungen anstellen.
Kristof bei Fooman

1

Gleiches Problem für mich.

"Zu spät ..." Fehler gefunden.

Nach dem Reinigen des cron_scheduleTisches hat cron.sh aufgehört zu arbeiten (keine Planung mehr).

Hat erst funktioniert, nachdem alle alten Cron-Prozesse beendet wurden.


In meinem Fall hat der Cron beim ersten Start die Tasks in der Tabelle erfolgreich erstellt. Aber es führt die Aufgabe niemals aus. :-(
Malaiselvan

1

Ich hatte das gleiche problem Mein Problem war zeitzonenspezifisch: Die Spalten created_atund scheduled_atin der cron_scheduleTabelle sollten UTC + 0 lauten, meine Einträge waren UTC + 2.

Um dies zu überprüfen, können Sie einfach die Daten von created_atund scheduled_atbis gestern einstellen und bis zum nächsten Cron-Zeitplan warten.

Hoffe das hilft jemandem!


1

Auf Bluehost in cron.sh ändern

 PHP_BIN=`which php`

zu

 PHP_BIN="php54s"

Im Shared Hosting läuft standardmäßig PHP 5.2.

Ich musste auch wechseln cron.phpund die beiden $isShellDisabledZeilen durch ersetzen$isShellDisabled = true;

Um PHP-Warnungen loszuwerden, habe ich diese Zeilen auch zuvor hinzugefügt

$_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';
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.