Türchen 15: Cronjobs im Magento

Cronjobs sind nicht gerade ein Thema, mit dem man auf einer Cocktailparty Eindruck schinden kann (gut: das gilt nur für 99% der Cocktailpartys ;-)). Für die Gesundheit eines Systems aber sind sie von essentieller Bedeutung, da sie sich um Aufgaben wie Datenwartung, Mailversand und den Austausch mit anderen Systemen kümmern. Das ist auch in Magento so.

Bei einem Großteil der Magento-Installationen sind die Cronjobs nicht richtig eingerichtet, wie auch beim Magento Developers Paradise 2012 beklagt wurde. Grund genug für mich, im heurigen Türchen eine Einführung zu geben und so dem einen oder anderen Cronjob zur Geburt zu verhelfen.

Cronjobs in Magento

Magento bringt bereits eine Reihe fertiger Jobs mit. Man muss sie nur noch einrichten, damit sie auch ausgeführt werden.

Für diesen Zweck findet man im Root-Verzeichnis der Magento-Installation das Skript cron.sh. Es ruft cron.php auf, das eine Rumpf-Version der Magento-Applikation startet und die dort definierten Cronjobs ausführt.

Magento verfügt nämlich über eine eigene Cronjob-Verwaltung. Dadurch ist es möglich, die Jobs in PHP zu programmieren und ihren Ablaufplan über die Konfiguration zu steuern.

Ein Hinweis vorab: dieses Türchen bezieht sich auf Linux-Systeme, da die allermeisten Shop-Installationen darauf laufen.

Einrichtung von cron.sh

Im ersten Schritt wird cron.sh für jenen Linux-User ausführbar gemacht, der die Cronjobs aufruft. Je nach Server-Setup müssen die Rechte für den Besitzer, die Gruppe oder für alle freigegeben werden. Generell gilt: je restriktiver die Rechte gesetzt werden können, desto besser.

Im zweiten Schritt trägt man den Job in crontab ein, also die Datei, welche die Aufgaben für cron auflistet. Das geht üblicherweise so:

crontab -e

Mit dem Befehl wird crontab geöffnet. Nun kann man den neuen Job eintragen:

/5 * /var/www/pfad/zu/magento/cron.sh

Diese Zeile bewirkt, dass Magentos Cron-Script alle 5 Minuten aufgerufen wird. Die genaue Syntax könnt ihr dem obigen Wikipedia-Link entnehmen. Achtet darauf, dass ihr crontab mit einer leeren Zeile abschließt, sonst wird der letzte Job in der Regel nicht ausgeführt.

Zudem ist wichtig, dass der User, der die Cronjobs ausführt, die benötigten Rechte hat!

Die Cronjobs sollten jetzt fertig eingerichtet sein. Habt ihr etwas falsch gemacht, dann erhält euer Linux-User Meldungen per Mail und ihr könnt euch auf die Fehlersuche machen.

Überprüfung und Konfiguration

Was tut Magento im Hintergrund? Es erstellt in regelmäßigen Abständen Jobs, die beim Aufruf durch cron ausgeführt werden. Die Konfiguration ist im Magento-Backend unter "System > Configuration > Advanced > System > Cron (Scheduled Tasks) - all the times are in minutes" zu finden:

cronjob_backend_configuration-650x327

Diese Einstellungen möchte man wahrscheinlich anpassen. Es ist ärgerlich, wenn fehlgeschlagene Cronjobs nur 10 Stunden archiviert werden und man Montag Morgen im Büro nicht feststellen kann, was denn am Wochenende genau schief gelaufen ist. (Sofern ihr kein automatisiertes Monitoring für Cronjobs verwendet.)

Um zu überprüfen, wie es den Cronjobs ergangen ist, kann man einen Blick in die Datenbank-Tabelle cron_schedule werfen:

cronjob_database

Hier werden alle generierten Jobs und ihr Status aufgelistet. Diese Ansicht ist leider nicht komfortabel. Die Cronjobs gehen in Magento dadurch unter.

Cronjob-Verwaltung 2.0

Wenn ich einen neuen Shop aufsetze, ist einer meiner ersten Schritte daher die Installation der Extension Aoe_Scheduler von Fabrizio Branca. Sie kann über modman, Composer oder Magento Connect eingerichtet werden. Ich empfehle modman oder Composer, da auf Magento Connect nicht die aktuelle Version zu finden ist.

Aoe_Scheduler fügt im Backend-Menüpunkt "System > Scheduler" drei neue praktische Ansichten hinzu:

  1. Überblick über die Cronjobs und ihre Konfiguration
  2. Die Liste der nächsten Jobs als Tabelle
  3. Eine graphische Darstellung der gelaufenen und geplanten Jobs

Anbei ein paar Screenshots, mit denen man einen guten Eindruck gewinnt.

aoescheduler_scheduleconfiguration-650x343
aoescheduler_listview-650x337
aoescheduler_timelineview-650x155

Die Extension birgt folgende Vorteile:

  • Aktivieren/Deaktivieren der Cronjobs ohne Eingriffe in Config-XML-Dateien
  • Übersicht über die Konfiguration und den Status der diversen Jobs
  • Kommandozeilen-Script und Web-Service-API-Befehle zum Erzeugen und Ausführen von Jobs
  • Ein "heartbeat"-Cronjob, der für die Überwachung der Cronjob-Funktionalität in Monitoring-Systemen verwendet werden kann

Besonders die Timeline-View erweist sich als hilfreich, da fehlgeschlagene Cronjobs farblich hervorgehoben werden und die Laufzeit der Jobs auf einen Blick ersichtlich ist. Beim Hovern über die Jobs erhält man weitere Details.

Magento-Standard-Cronjobs

Nun ist es an der Zeit, die von Magento mitgelieferten Jobs durchzugehen, nicht benötigte zu deaktivieren und die Ablaufpläne (falls nötig) anzupassen. Sehen wir uns an, welche Jobs die Magento Community Edition 1.7 bietet.

Backup

Code Cron Expression Model
system_backup backup/observer::scheduledBackup

Auf Wunsch führt Magento mit dem Job "system_backup" Sicherungen der Datenbank, Media- und/oder Code-Dateien durch. Damit das Backup erstellt wird, muss es über den Menüpunkt "System > Configuration > Advanced > System > Scheduled Backup Settings" konfiguriert werden.

Wer sich über das seit 1.7 erhältliche Backup-/Rollback-Feature informieren möchte, findet dazu einen Beitrag in meinem Blog. Falls ihr die Daten auf anderen Wegen sichert, könnt ihr den Job ruhig über Fabrizios Extension deaktivieren. Auf irgendeine Weise muss aber gesichert werden.

Cache

Code Cron Expression Model
core_clean_cache 30 2 * * * core/observer::cleanCache

Der Job "core_clean_cache" leert veraltete Cache-Einträge. Es wird also nicht alles gelöscht. Und kaum, dass ich das geschrieben habe, muss ich es relativieren. Welche Einträge betroffen sind, hängt nämlich von den eingesetzten Cache-Backends und einigen Settings ab. Gute Informationen zur Cache-Problematik liefert Fabrizio.

CAPTCHAs

Code Cron Expression Model
captcha_delete_expired_images */10 * * * * captcha/observer::deleteExpiredImages
captcha_delete_old_attempts */30 * * * * captcha/observer::deleteOldAttempts
CAPTCHAs sind verschnörkelte Buchstaben- und Zahlenfolgen, auf die man bei Web-Formularen immer wieder stößt. Sie sollen Shopbetreiber vor Unmengen an Spam-Mails schützen. Die Option, CAPTCHAs in diversen Backend- und Frontend-Formularen einzubinden, wurde ebenfalls mit Magento 1.7 in Magento integriert (siehe CAPTCHAs in Magento 1.7). Leicht zu erkennen ist die Aufgabe der Jobs: einerseits werden nicht mehr benötigte CAPTCHA-Bild-Dateien gelöscht, andererseits alte Einträge in der Log-Datenbank zu (fehlgeschlagenen) CAPTCHA-Lösungsversuchen. Wer CAPTCHAs nicht im Einsatz hat, kann diese Cronjobs deaktivieren.

Google Sitemap

Code Cron Expression Model
sitemap_generate sitemap/observer::scheduledGenerateSitemaps
Genau genommen handelt es sich bei den Sitemap-XML-Dateien, die "sitemap_generate" erstellt, ja gar nicht um eine reine Google-Sitemap-Datei. Yahoo und co. verwenden diesen Standard ebenso. Aufgrund der Marktmacht von Google hat sich aber auch Magento zur Bezeichnung "Google Sitemap" hinreißen lassen. Sei's drum: es geht um die Erzeugung der Sitemap-Datei, die üblicherweise sitemap.xml heißt und im root-Verzeichnis der Magento-Installation abgelegt wird. Sie hilft Suchmaschinen, die Seiten des Angebots zu finden und entsprechend der Wünsche des Betreibers zu priorisieren. Damit Sitemap-Dateien automatisch angelegt werden, müssen zwei Schritte erfolgen:
  1. Die Sitemaps müssen im Hauptmenüpunkt "Catalog > Google Sitemap" angelegt werden.
  2. Der Cronjob muss in "System > Configuration > Catalog > Google Sitemap" aktiviert und konfiguriert werden.

Katalog

Code Cron Expression Model
catalog_product_index_price_reindex_all 0 2 * * * catalog/observer::reindexProductPrices
catalogrule_apply_all 0 1 * * * catalogrule/observer::dailyCatalogUpdate
catalog_product_alert productalert/observer::process
Jobs, die den Produktkatalog betreffen, sind auf verschiedene Module verteilt. "catalogrule_apply_all" berechnet Produktpreisänderungen aufgrund der Katalogpreisregeln. Berücksichtigt wird ein 3-Tage-Intervall bestehend aus dem vorangegangenen, dem aktuellen und dem nächsten Tag. "catalog_product_index_price_reindex_all" sorgt dann dafür, dass die Produktpreise auf dem laufenden Stand sind. Die Preise sollten bei einer automatischen Indizierung sowieso stimmen, doch solange keine anderen Parameter dagegen sprechen (Laufzeit des Jobs, Caching), kann eine Neuindizierung nicht schaden. Über "catalog_product_alert" werden Hinweis-Mails versendet, wenn sich Produktpreise ändern oder ein nicht lagerndes Produkt wieder verfügbar ist. Ob diese Funktionen zur Verfügung stehen, wird in "System > Configuration > Catalog > Catalog > Product Alerts" bzw. "System > Configuration > Catalog > Catalog > Product Alerts Run Settings" konfiguriert.

Logs

Code Cron Expression Model
log_clean log/cron::logClean
Magento erzeugt Unmengen an Log-Daten. Wer nicht aufpasst, kann bald in zig Gigabyte (GB) an Datenbankeinträgen untergehen. Das verlängert Backup- und Rollback-Operationen. Nicht zuletzt kann die Performance darunter leiden. Um das zu verhindern, veranlasst man in "System > Configuration > Advanced > System > Log Cleaning" die Bereinigung der Log-Tabellen um alte Datensätze. Wer diese Daten weiterhin benötigt, kann eigene Jobs schreiben, welche die Daten rechtzeitig wegschreiben, bevor "log_clean" sie ins digitale Nirvana schickt.

Magento Mobile

Code Cron Expression Model
xmlconnect_notification_send_all */5 * * * * xmlconnect/observer::scheduledSend
Mage_XmlConnect ist eines dieser Module, mit denen die meisten Entwickler nie in Berührung kommen. Im Prinzip dient es dem Betrieb von Magento Mobile Apps. Wer eine solche App eingerichtet hat, sollte daher den Cronjob aktiviert lassen.

Newsletter

Code Cron Expression Model
newsletter_send_all */5 * * * * newsletter/observer::scheduledSend
"newsletter_send_all" kommt zum Einsatz, wenn Newsletter über die Magento-eigene Funktion verschickt werden. Der Job wird benötigt, da Magento die Mails verteilt versendet, um u.a. die Gefahr zu senken, dass der Server als Spam-Server eingestuft wird. Achtung: im Magento-Standard ist hard kodiert, dass pro Durchlauf maximal je 20 E-Mails gesendet werden. Große Mail-Listen benötigen daher geraume Zeit, um verschickt zu werden und der Einsatz ist so nur mäßig sinnvoll.

PayPal

Code Cron Expression Model
paypal_fetch_settlement_reports paypal/observer::fetchReports
Wer PayPal direkt über Magento einbindet, kann "paypal_fetch_settlement_reports" einsetzen, um die Settlement Reports automatisiert abzuholen. Das Konfigurationsmenü für die Settlement Reports findet man rekordverdächtig gut versteckt unter "System > Configuration > Sales > Payment Methods > PayPal All-in-One Payment Solutions > PayPal Payments Advanced (Includes Express Checkout) > Required PayPal Settings > Basic Settings - PayPal Payments Advanced > Advanced Settings > Settlement Report Settings". Zuerst trägt man die SFTP-Zugangsdaten ein, dann konfiguriert man unter "Scheduled Fetching" den Job. Alle ohne diese Zahlmethode deaktivieren den Eintrag und freuen sich, dass sie nicht mit Grubenlampe und Spitzhacke 10 Ebenen tief in die Konfiguration eintauchen müssen.

Quotes & Warenkorb

Code Cron Expression Model
persistent_clear_expired 0 0 * * * persistent/observer::clearExpiredCronJob
sales_clean_quotes 0 0 * * * sales/observer::cleanExpiredQuotes
Wer unter "System > Configuration > Customers > Persistent Shopping Cart" den persistenten Warenkorb aktiviert hat, kann mit "persistent_clear_expired" dafür sorgen, dass abgelaufene Sessions aus der Datenbank entfernt werden. "sales_clean_quotes" kümmert sich darum, dass Quotes gelöscht werden, die zu einer Order geführt haben und älter sind als die in "System > Configuration > Sales > Checkout > Shopping Cart > Quote Lifetime (days)" angegebenen Tage. Richtig gelesen: aktive Quotes, also Warenkörbe, die noch nicht in eine Bestellung umgewandelt wurden, werden von Standard-Magento nie gelöscht. Auch hier können ähnlich wie bei Logs Unmengen von Datenleichen entstehen. Wir kommen gleich noch zu einer Extension, die diesen Umstand bereinigt.

Verkäufe und Reporting

Code Cron Expression Model
aggregate_sales_report_bestsellers_data 0 0 * * * sales/observer::aggregateSalesReportBestsellersData
aggregate_sales_report_invoiced_data 0 0 * * * sales/observer::aggregateSalesReportInvoicedData
aggregate_sales_report_order_data 0 0 * * * sales/observer::aggregateSalesReportOrderData
aggregate_sales_report_refunded_data 0 0 * * * sales/observer::aggregateSalesReportRefundedData
aggregate_sales_report_shipment_data 0 0 * * * sales/observer::aggregateSalesReportShipmentData
aggregate_sales_report_coupons_data 0 0 * * * salesrule/observer::aggregateSalesReportCouponsData
aggregate_sales_report_tax_data 0 0 * * * tax/observer::aggregateSalesReportTaxData
Aufgabe dieser Jobs ist das Aggregieren diverser Daten rund um Verkäufe und die Bestellabwicklung. Wenn Händler die Reports in Magento nicht verwenden, würde ich diese Jobs deaktivieren. Immer häufiger werden die Analysen in externen ERP-Systemen oder Data-Warehouses vollzogen, womit die ohnehin nicht problemlos funktionierende Reporting-Funktion obsolet wird. Falls die Reporting-Funktion eingesetzt wird, kann es abhängig vom Datenvolumen und Besucheraufkommen des Shops sinnvoll sein, die Jobs zeitversetzt laufen zu lassen.

Währungen

Code Cron Expression Model
currency_rates_update 0 0 * * * directory/observer::scheduledUpdateCurrencyRates
Dieser Task zur Aktualisierung der Währungskurse wird unter "System > Configuration > General > Currency Setup > Scheduler Import Settings" aktiviert. Auch hier gilt: wer das Feature nicht verwendet, kann es guten Gewissens über Aoe_Scheduler deaktivieren.

Ablaufpläne der Standard-Jobs verändern

Nachdem wir nun feststellen können, welche Cronjobs für uns relevant sind, geht es an die Ablaufplanung (wer es lieber englisch hat: "scheduling"). Einige Jobs bieten die Möglichkeit, die Ablaufpläne über Einträge in "System > Configuration" zu verändern. Wer Tasks umplanen möchte, welche diese Option nicht bieten oder wer Änderungen direkt über Files warten will, kann das in der Datei config.xml seiner Extension tun:
<?xml version="1.0" encoding="UTF-8"?>
<config>
    <!-- Restliche Konfiguration -->
    <crontab>
        <jobs>
            <catalog_product_index_price_reindex_all>
                <schedule>
                    <cron_expr>30 1 * * *</cron_expr>
                </schedule>
            <catalog_product_index_price_reindex_all>
        </jobs>
    </crontab>
</config>
Einfach den Code des Cronjobs verwenden und eine Schedule festlegen, schon ist die Sache erledigt. Außerdem muss man dafür sorgen, dass die eigene Extension nach dem entsprechenden Magento-Modul geladen wird.

Eigene Cronjobs hinzufügen

Eigene Cronjobs lassen sich denkbar einfach festlegen. Nötig sind nur:
  • der Name ("code") für den Cronjob
  • eine Schedule (in Form einer Cron-Expression oder eines Hinweises, in welchem "System > Config"-Eintrag man die Cron-Expression findet)
  • das Model und die Methode, die aufgerufen werden sollen.
Mit diesem Code werden zwei Jobs mit jeweils einer Art de Schedule-Definition eingerichtet:
<?xml version="1.0" encoding="UTF-8"?>
<config>
    <!-- Restliche Konfiguration -->
    <crontab>
        <jobs>
            <webguys_cronjob_one>
                <schedule>
                    <cron_expr>0 */2 * * *</cron_expr>
                </schedule>
                <run>
                    <model>webguys_example/observer::cronjobOne</model>
                </run>
            </webguys_cronjob_one>
            <webguys_cronjob_two>
                <schedule>
                    <config_path>webguys/example/cronjob_two</config_path>
                </schedule>
                <run>
                    <model>webguys_example/observer::cronjobTwo</model>
                </run>
            </webguys_cronjob_two>
        </jobs>
    </crontab>
</config>

Nützliche Extensions

Zum Abschluss Hinweise auf einige Extensions, die ich regelmäßig bei Magento-Shops für die Datenwartung nutze und bei denen Cronjobs eine wichtige Rolle spielen:
  • Aoe_AsyncCache: schreibt Lösch-Befehle für den Cache in eine Queue, anstatt sofort zu löschen (asynchrones Cache-Löschen). Dadurch wird der Cache seltener gelöscht und bestimmte Operationen wie der Backend-Login beschleunigt. Der Cronjob für die tatsächliche Löschung der Cache-Einträge wird standardmäßig alle 15 Minuten ausgeführt.
  • Aoe_CacheCleaner: leert verschiedene Teile des Caches (den gesamten Cache, den Magento-Cache, JS/CSS, Katalogbilder). Die Schedule ist für jeden Teil getrennt konfigurierbar.
  • Aoe_QuoteCleaner: löscht alte Warenkörbe / Quotes unabhängig davon, ob sie in eine Bestellung überführt wurden. Wie oben erwähnt ist das sinnvoll, um die Datenmenge nicht zu stark ansteigen zu lassen. Wie lange man hofft verwaiste Warenkörbe noch reaktivieren zu können, ist mitunter eine Marketing-Frage. Wenn der Warenkorb trotz aller Bemühungen z.B. sechs Monate unberührt geblieben ist, kann man die Quote aber wohl ohne Bedenken löschen.

Fazit

Dieser Überblick hilft hoffentlich dem/der einen oder anderen, die saubere Basis für ein gesundes Shopsystem zu legen. Falls ihr Tipps für die Nutzung von Cronjobs oder weitere Extensions habt, freue ich mich über eure Kommentare.


Ein Beitrag von Matthias Zeis
Matthias's avatar

Matthias Zeis lebt in Wien und ist für Onlineshop-Projekte bei LimeSoda zuständig. Er arbeitet seit 2009 mit Magento, ist seit 2011 Magento Certified Developer und organisiert seit 2012 den ersten Magento-Stammtisch Österreichs. Wer Lust auf mehr bekommen hat, findet Matthias bei matthias-zeis.com, LimeSoda, Twitter (@mzeis) oder GitHub.

Alle Beiträge von Matthias

Kommentare
Momcilo am

Hallo, ich hatte das gleiche Problem dass alle Jobs im Status "pending" blieben. Manchmal sind 1-2 Jobs gelaufen und das war's dann.

Das Problem habe ich behoben in dem ich die Zeile PHP_BIN=which php im cron.sh

durch PHP_BIN=“/usr/bin/php5"

ersetzt habe. Die Ausgabe PHP_BIN=which php war in meinem Fall der Pfad zu php4. Hoster ist Alfahosting.

Vielleicht hilft das jemandem.

Grüße, Momcilo

Matthias Zeis am

Hallo,

ich würde zuerst auf die aktuelle Version von Aoe_Scheduler (1.2.1) upgraden und Crontab wie dort vorgeschlagen konfigurieren (siehe dazu den neuen Menüpunkt in Aoe_Scheduler).

Ob die Rechte so stimmen kommt auf die Server-Konfiguration an. Idealerweise wird der Cronjob für den Webserver-User eingerichtet. Ist das nicht möglich, dann kann man z.B. den Cronjob unter seinem SSH-User laufen lassen, wobei Webserver- und SSH-User in derselben Gruppe sein und entsprechende Group-Permissions gesetzt sein sollten. 770 klingt danach als ob du zweiteres Setup hast.

Beste Grüße Matthias

Aloha am

Hallo Zusammen

ich bekomm es leider nicht hin. Habe Magento ver.1.9.2.1 Aoe_Scheduler 0.3.2 (stable)

Bei mir läuft Scheduler irgend wie nicht automatisch. Ich muss jedesmal über Menüpunkt Scheduler/Configuration/Verfügbare Aufgaben/Alle wählen/Aktion: Run Now klicken damit das auch funktioniert. Und sieht alles grün aus. Bestell-Mails Hinweis & Kommentar Änderungen über Bestellungen gehen auch als Mail raus. Aber nur dann wenn ichs Manuell mache.

Im Cron.sh datei habe ich wie oben beschrieben folgendes eingetragen(ganz unten): crontab -e /5 * /www/magento/cron.sh

CHMOD auch auf 770 gesetzt

im Chron.sh Datei steht nun folgendes:

if [ ! "$1" = "" ] ; then CRONSCRIPT=$1 else CRONSCRIPT=cron.php fi

MODE="" if [ ! "$2" = "" ] ; then MODE=" $2" fi

PHP_BIN=which php

absolute path to magento installation

INSTALLDIR=echo $0 | sed 's/cron.sh//g'

prepend the intallation path if not given an absolute path

if [ "$INSTALLDIR" != "" -a "expr index $CRONSCRIPT /" != "1" ];then if ! ps auxwww | grep "$INSTALLDIR$CRONSCRIPT$MODE" | grep -v grep 1>/dev/null 2>/dev/null ; then $PHP_BIN $INSTALLDIR$CRONSCRIPT$MODE & fi else if ! ps auxwww | grep "$CRONSCRIPT$MODE" | grep -v grep | grep -v cron.sh 1>/dev/null 2>/dev/null ; then $PHP_BIN $CRONSCRIPT$MODE & fi fi

crontab -e /5 * /www/magento/cron.sh

müsste das was ich manuell mache, nicht alle 5min automatisch laufen?! Oder verstehe ich da mit Aoe_Scheduler was falsch?!

Dank im Voraus Aloha

Bert am

Hi Chris,

gibt es Fehlermeldungen des cron-Jobs auf Hosterebene? Ich hatte mal ein Problem mit den Rechten. Die cron.sh durfte nicht ausgeführt werden, habe sie dann auf 770 gestellt und es passte. Gruß Bert

Chris am

Hallo, ich habe die wohl hier schon dutzende Male beschriebene Meldung (No heartbeat task found. Check if cron is configured correctly) und es scheint egal was ich wie tue es bleibt wie es ist...ich verzweifle :-(( Alle Aufgaben stehen auf "pending" und dort bleiben sie stehen...

Die Meldung "add following configuration" ergibt nur etwas was eigentlich schon eingerichtet ist. Ich habe etliche Cronjobs configuriert und dachte mir passiert hier kein Fehler, und jetzt?... Ich weiss, dass ich hier nun wenig hilfreiche Fakten schreibe aber hat jemand schon ähnliche Erfahrungen gemacht, dass prinzipiell alles passen müsste aber nichts geht? Also, nur zur Info ich arbeite seit 2009 mit Magento und kenne die "Basics" ;-) nach dutzenden eingerichteten Shops...

Ich frage hier einfach ins Blaue, weil vielleicht gibt es irgendetwas, dass selten vor kommt und genau das ist es was ich grad nicht "sehe" wegen Magento-Betriebsblindheit :-))...die im Artikel beschriebenen Punkte sind grundsätzlich alle abgearbeitet.

Grüße und für jede Hilfe Meeeegaaaa Danke! Chris

Bert am

Hallo zusammen,

der Cron-Daemon meines Hosters meldet

Cannot find /proc/version - is /proc mounted?

Mein Hoster sagt, ich habe darauf keinen Zugriff, bekomme auch keinen und soll den Aufruf aus dem entsprechenden Skript löschen. Ich habe leider keine Ahnung welches Skript den Aufruf tätigt und wie die Syntax im Skript aussieht. Kann mir einer helfen?

Danke & Gruß Bert

RCTech am

Danke für den Artikel, hat mir geholfen!

Thea am

Wenn Sie irgendein Problem mit cron-Job zu erleben, können Sie kostenlose Online-Cron-Job-Anbieter wie https://www.easycron.com versuchen.

Andreas am

In 1.7.0.2 wird Mage::app()->getCache()->clean(Zend_Cache::CLEANING_MODE_OLD); in Core/Model/observer.php ausgeführt.

Das AOE-Plugin ist unnötig.

Setting Up Magento Cron Job | Yogu Manivannan am

[…] (english) http://www.webguys.de/magento/adventskalender/turchen-15-cronjobs-im-magento/ […]

Matthias Zeis am

Hier gibt es Beispiel-Code, wie man einen Cronjob erstellt, der direkt in Magento verwaltet wird: http://stackoverflow.com/a/11202686/558524

Der Cron-Ausdruck für 1 Uhr morgens ist "0 1 *" (ohne Anführungszeichen). In der Klassenmethode kann man den Code schreiben, um die Session-Files zu löschen.

Wir löschen die Sessions allerdings nicht über einen Magento-Cronjob. Zum Umgang mit Session-Files siehe http://magento.stackexchange.com/questions/41/how-should-i-handle-session-files-that-become-too-numerous (nicht nur meine Antwort, die alternative Cache-Backends vorschlägt sondern auch die Antwort darunter, in der ein Shell-Befehl steht, mit dem an die Session-Files löscht).

dr.kruno am

Hallo ich wollte mal erfragen wie man am besten einen eigenen cronjob in die Extension enbindet!?

Ich würde gerne jeden Tag um 1:00h ein script ausführen, welches mir die session files unter magento_root/var/session/ löscht.

Ich habe z.B über PLESK geplante Aufgaben folgendes erfolgreich zum laufen gebraucht:

find /var/www/vhosts/mobility4less.de/httpdocs/var/session/ -type f -mtime +1 -exec rm -f {} \;

dieser Befehl wird jeden Tag um 1h nachts ausgeführt.

Ich würde gerne diesen Cronjob aber über die AOE SCHEDULER Extension verwalten...

Muss ich jetzt eine .php Datei erzeugen mit diesen Befehl erstellen? Und sie unter httpdocs speichern? Z.B. bennen ich sie session_remove.php mit dem Inhalt:

Wie binde ich diese aber in die AOE SCHEDULER Extension ein, ohne Plesk dabei nutzen zu müssen???

Danke für jeden Hinweis.

Steffen Schaumburg am

Auch von mir vielen Dank!

HinDL am

Vielen Dank für den tollen Beitrag!

Matthias Zeis am

Die Meldung “No heartbeat task found. Check if cron is configured correctly.” taucht nur auf, wenn kein erfolgreich ausgeführter "aoescheduler_heartbeat"-Task in der Cron-Tabelle von Magento steht. Das ist der Fall, 1.) wenn der Job noch nie ausgeführt wurde oder 2.) er nicht mehr ausgeführt wird und alle alten "aoescheduler_heartbeat"-Jobs aus der Tabelle gelöscht wurden.

Noch ein Hinweis, warum Cronjobs eventuell nicht ausgeführt werden: cron.sh überprüft, ob bereits ein Linux-Prozess für genau dieses Script läuft. Wenn ja, dann wird es nicht noch einmal ausgeführt. Hängt also ein Linux-Prozess und taucht in "ps auxwww" auf, dann werden weitere Jobs nicht mehr ausgeführt.

Flare am

Noch eine Eränzung. Ich habe den task "aoescheduler_heartbeat " nun manuell gestartet und die Meldung ist jetzt weg.

Jetzt erhalte ich die Meldung: "Scheduler is working. (Last execution: 2 minute(s) ago)"

Mal sehen wie sich das jetzt weiter verhält.

Flare am

Toller Beitrag vielen Dank. Ich habe die selbe Meldung wie Matthias:

“No heartbeat task found. Check if cron is configured correctly.”

Der Cronjob wurde eingerichtet und die cron.sh wird alle 5 Minuten aufgerufen. Es scheint eigentlich alles zu funktionieren. Was muss ich machen um diese Meldung weg zu kriegen? Muss ich nochmals einen Cron erstellen und eine andere Datei aufrufen?

Vielen Dank für die Hilfe.

Matthias Zeis am

@micha: Danke. Was meinst du mit der Schedule- und NOW-Time?

@Matthias:

ad a) Das bedeutet normalerweise, dass cron.sh noch nicht in crontab eingetragen wurde und die Cronjobs daher nicht aufgerufen wurden. Falls Sie die Extension gerade erst installiert haben, ist der Cronjob vielleicht nicht gelaufen.

ad b) Ich weiß nicht, ob ich die Frage richtig verstehe. Falls es darum geht, wie man den richtigen Linux-User den Cronjob ausführen lassen kann: http://stackoverflow.com/questions/8475694/how-to-specify-in-crontab-by-what-user-to-run-script

ad c) Genau, das vermute ich.

Matthias am

Danke für die Beschreibung. Leider habe ich noch ein Fragen und würde mich freuen, wenn Sie mir ein paar Tipps geben können.

Nach Installation und Anlage der crontab verhält es sich folgendermaßen. a) in der Extension erhalten ich die Rückmeldung "No heartbeat task found. Check if cron is configured correctly." Was bedeutet das?

b) Wie stelle ich die Userrechte ein? Mit welchen Befehlen? chmod und wie erhalte ich relevante User?

c) Im Schedule Timliner sehe ich, dass die Jobs nicht ausgeführt wurden. Alle grau, auch wenn der Ausführungszeitpunkt bereits überschritten ist. Hängt das mit a) und b) zusammen?

Wäre um eine Antwort sehr dankbar.

Gruß Matthias

micha am

Sehr schöne Artikel! Super Verweis und Erklärung der Extension. Jetzt habe ich mal eine Blöde Frage zur Extension:

kann ich über die Extension irgendwie auch die Schedule-Time bestimmten? Es ist nur möglich die NOW-Time zu bestimmen. Oder habe ich mir auf GitHub die Falsche Version gezogen?

Dein Kommentar