Welches Cron-Skript ist am besten geeignet? cron.php oder cron.sh

Magento stellt zwei Cron-Skripte in seinem Stammverzeichnis zur Verfügung, cron.php und cron.sh.

Welcher ist der bessere und warum?

cron

— Joe
quelle

Am besten führen Sie cron.sh aus

Ab Magento EE 1.13.x und CE 1.8.x wurde die Cron-Mechanik geändert, und Magento hat eine neue Scheduling-Modus-Funktion eingeführt.

Es gibt 2 verfügbare Modi: 1. Standard - führt geplante Cron aus. 2. always - Wie der Name schon sagt, werden diese Tasks bei jedem Auslösen von cron bedingungslos ausgeführt und benötigen keine explizit definierten Zeitpläne.

Grundsätzlich wird cron.php ohne Parameter aufgerufen und verwendet shell_exec, um zwei Prozesse von cron.sh auszuführen. Jeweils mit einem anderen Parameter ("default" oder "always"). Cron.sh wiederum übergibt diesen Parameter an cron.php, das dann den cron ausführt. Intern verwendet Magento seine Ereignisinfrastruktur, um die beiden Modi zu verarbeiten, indem Ereignisse mit den Namen "default" und "always" ausgelöst werden. Mage_Cron implementiert dann zwei Observer-Methoden.

Wenn Sie sich cron.php ansehen, werden Sie feststellen, dass die PHP-Funktion shell_exec verwendet wird. Abgesehen davon, dass dies ein Sicherheitsrisiko darstellt, kann die Funktion NULL zurückgeben, wenn ein Fehler auftritt oder das Programm keine Ausgabe erzeugt. Mit dieser Funktion können keine Ausführungsfehler erkannt werden. Dies bedeutet, dass zu jedem Zeitpunkt, zu dem Ihr Skript / Code aufgrund eines Fehlers fehlschlägt, Folgendes passiert: 1. Der Cronjob wird veraltet, 2. Es wird kein Fehler aufgezeichnet, 3. und niemand weiß, dass dies geschehen ist.

Um dies zu überwinden, sollten die folgenden Cronjobs hinzugefügt werden:

*/5 *   * * *   www-data /bin/sh /path/to/magento/cron.sh cron.php -m=default
*/5 *   * * *   www-data /bin/sh /path/to/magento/cron.sh cron.php -m=always

Dadurch wird sichergestellt, dass die Prozessmodi immer ohne die Verwendung der Fallback-PHP-Funktion shell_exec ausgeführt werden und dass der Cron nicht veraltet wird, da im Fehlerfall eine Ausnahme ausgelöst wird.

— Shaughn
quelle

Ich möchte nur hinzufügen, dass der obige Beispiel-Cron-Ausdruck ziemlich allgemein ist. www-datawürde sich auf jeden Benutzer ändern, der Webserverprozesse ausführt. Erwähnenswert shell_exec()ist auch, dass für viele CPanel / WHM-Hosting-Setups deaktiviert werden wird.

— pspahn

*/5 * * * * www-data /bin/sh /path/to/magento/cron.sh cron.php -m=default */5 * * * * www-data /bin/sh /path/to/magento/cron.sh cron.php -m=always

und diese befehle geben "befehl nicht gefunden" fehler von nupur walia

— bera

Wenn Sie diese Fehlermeldung erhalten, müssen Sie drei Dinge überprüfen: 1) www-data ist der richtige Benutzer auf diesem Server, der diesen Prozess ausführen kann, andernfalls ändern Sie ihn in einen beliebigen Benutzer. 2) Überprüfen Sie den Speicherort von sh. Führen Sie also "which sh" aus und geben Sie den Speicherort aus. Dies ersetzt "/ bin / sh", wenn es sich um einen anderen Pfad handelt. 3) Überprüfen Sie abschließend, ob der Pfad zu cron.sh tatsächlich korrekt ist.

— Shaughn

@AmitBera Ich erhielt die gleiche Fehlermeldung und konnte sie nicht für WWW-Daten, Root oder andere Benutzer verwenden. Ich habe eigentlich nur den Benutzer ausgelassen und es funktioniert jetzt, also*/5 * * * * /bin/sh /path/to/magento/cron.sh cron.php -m=default

— Michael

@Shaughn kannst du erklären, was der Standard- und der Always-Modus verwendet?

— Rohan Hapani