Drupal - Gratis-Cronjob einrichten

Was ist Cron?

Cron ist ein Hintergrundprogramm, das auf unixartigen Betriebssystemen immer dann ins Spiel kommt, wenn in regelmäßigen Zeitabständen bestimmte Programme oder Skriptdateien wieder und wieder aufgerufen werden sollen. Cron ist nicht für einmalige Programmausführungen gedacht.

Um diese Aufgabe zu erfüllen, liest Cron im Minutentakt sowohl systemweite als auch benutzerdefinierte Tabellen ein (das sind die sog. Crontabs), um dann die darin festgelegten Cronjobs auszuführen, sofern die beim Job stehende Zeitangabe auf die aktuelle Zeit zutrifft. Als Cronjob wird jenes Programm bezeichnet, das zu bestimmten Zeitpunkten gestartet werden soll. Da Cron seinerseits die Dateien immer neu einliest, muss es nach dem Editieren der Crontabs durch einen Benutzer oder Administrator nicht neu gestartet werden (wie dies etwa bei anderen Diensten der Fall ist). Der minimale Zeitabstand zwischen zwei durch Cron angestoßenen Cronjob-Ausführungen beträgt 1 Minute, der maximale 1 Jahr.

Warum gibt es Cronjobs?

Wozu dient aber nun der Cron-Mechanismus und wozu sind die Cronjobs gut? In bescheidenen Grenzen verfügen Systeme im allgemeinen, dabei natürlich auch Betriebssysteme oder Content Management Systeme wie Drupal im speziellen, über Selbstregulierungsmechanismen, die ihrem Funktionserhalt dienen. Die Selbstregulierung wiederum dient der Entlastung der Administratoren oder des überwachenden Personals und ist somit eine gute Sache ;-)
Cronjobs sind typischerweise von Cron zyklisch gestartete Programme, die

  • System- und Hardwarefunktionen überwachen,
  • Protokolldateien warten (komprimieren, umbenennen, übers Netz kopieren),
  • Datensicherungen erstellen und auf andere Rechner kopieren,
  • Software-Updates auf Verfügbarkeit prüfen,
  • ereignisgebunden Nachrichten verschicken (E-Mail, SMS).

So wird ein Webserver z. B. in der Regel automatisch daraufhin überwacht, ob er Webseiten ausliefern kann – falls nicht, kann das Skript selbsttätig versuchen, den Webserver neu zu starten und (sollte dies misslingen) ggf. den Administrator per SMS verständigen – jedenfalls aber wird es den Vorfall protokollieren.

Drupal's Herzschlag: die cron.php

Drupal's Schnittstelle zum Cron-Dienst eines beliebigen Servers ist ein PHP-Skript und heißt cron.php. Diese Skript-Datei liegt immer im Drupal-Installationsverzeichnis.

Die cron.php hat eine Besonderheit: sie muss über das HTTP-Protokoll (also ein Programm, das sich wie ein Webbrowser verhält) aufgerufen werden, da im HTTP-Header der Domainname mitgeschickt wird und vom Skript benötigt wird. In Multisite-Umgebungen muss sie für jede Domain gesondert aufgerufen werden.

Das bedeutet zugleich, dass jeder Webbrowser, über dessen Adressleiste die cron.php unserer Drupal-Installation aufgerufen wird, den Cronjob einmalig ausführt. Andererseits wird es nicht funktionieren, wenn man als lokaler Systembenutzer versuchen sollte, den Befehl für den Drupal-Cronjob als "/usr/bin/php /var/www/web4711/htdocs/cron.php" zu definieren.

Die cron.php befragt alle aktivierten Kern- und nachinstallierten Module Drupal's nach einer Funktion namens MODULNAME_cron() und sorgt – sollte diese Funktion existieren – für deren Ausführung.

Kernmodule, die cron benötigen:

  • aggregator (ruft neue Beiträge anderer Sites ab)
  • dblog (löscht alte Protokolleinträge aus der Datenbank)
  • filter (löscht veraltete Cache-Datensätze)
  • node (löscht alte Protokolleinträge von Benutzerzugriffen auf Nodes)
  • ping (benachrichtigt andere Sites über neue Beiträge meiner Site)
  • poll (beendet Umfragen nach Ablauf vordefinierter Zeiträume)
  • search (aktualisiert den Suchindex um Begriffe neuer Beiträge seit dem letzten Cron-Lauf)
  • statistics (löscht alte Protokolleinträge)
  • trigger (löst crongebundene Aktionen aus)
  • update (sucht nach Aktualisierungen aktivierter Module auf drupal.org und benachrichtigt den Site-Admin per E-Mail, sofern dies konfiguriert wurde)

Beispiele für Nicht-Kernmodule, die cron benötigen ("Contributed Modules")

In diesen Modulen habe ich persönlich einmal eine XXX_cron-Funktion gefunden (was daher keinesfalls auf eine vollständige Liste schließen läßt!): audio, akismet, calendar, ecommerce, panels, subscriptions, simplenews, update_status (Drupal 5), ubercart, video, voting_api (fivestar), workflow

Drei Möglichkeiten von Cron-Läufen für Drupal

  1. Man ruft die cron.php manuell über die Adressleiste eines Webbrowsers auf. Die unverläßlichste Methode, da man dies über kurz oder lang vernachlässigen wird.
  2. Die "halbautomatische" Methode. Dabei wird das Modul Poormanscron installiert, aktiviert und konfiguriert. Zu den Vor- und Nachteilen siehe weiter unten.
  3. Der echte Cronjob, also der, der diesen Namen verdient. Man braucht dafür entweder Shell-Benutzerzugang zu einem Server (zu einem, der immer online ist, z. B. einem Fileserver) oder man richtet einen Cronjob webbasiert ein. Dies kann entweder über die Admin-Benutzeroberfläche des Providers geschehen, sofern der einem die Konfiguration von Cronjobs erlaubt – oder man registriert sich bei einem Bezahl- bzw. Gratis-Cronjob-Anbieter. Eine solche beispielhafte Einrichtung (bei einem Gratis-Anbieter) wird oben im Screencast gezeigt.

Der Armeleute-Cron: Poormanscron

Kurz gesagt: man lasse besser die Finger davon.

Nicht, dass das Ding nicht funktionieren würde. Der Poormanscron kann sogar nützlich sein: z. B. beim Debuggen der fehlerhaften Cron-Funktion eines noch unbekannten Moduls. Da kann der Poormanscron für jedes aufrufende Modul einen Protokolleintrag schreiben und das schuldige Modul ist schnell gefasst. Und das kann das native Cron von Drupal in dieser Form übrigens nicht! Aber als Ersatz für einen echten Cronjob ist der Poormanscron doch ein Schritt rückwärts. Warum?

Bei jedem einzelnen Seitenzugriff auf die Site (auch von den Bots!) wird geprüft, ob die cron.php aufgerufen werden muss. Dafür sind Datenbankzugriffe und eine Zeitberechnung notwendig. Das kostet bei stark frequentierten Sites (und Drupal's Ehrgeiz ist eben dies: dafür ein CMS-Framework zu liefern!) signifikant Performance. Ein Cronjob im 5-Minuten-Takt ist da weitaus ressourcenschonender.

Desweiteren sind durch die Abhängigkeit von Seitenaufrufen keine regelmäßigen Cron-Läufe zu erwarten. Das ist so, als würde man sich immer erst dann die Zähne putzen, wenn einer vorbeikommt und einem klarmacht, dass es schlecht riecht. Dann erst zur allgemeinen Toilette davonzustürzen wäre wohl kein guter Stil :-)

Ein Beispiel für Poormanscron's mögliches Versagen ist dies: nehmen wir an, ein Autohausbesitzer betreibt eine Drupal-Site und verkauft über den Shop dieser Site (der übrigens schlecht besucht ist) ein Auto pro Monat. Nun immerhin! Das rechnet sich ja trotzdem. Sein Webdesigner hatte aber seinerzeit den Poormanscron als Cron-Lösung gewählt; und nachdem eines Tages einmal eine Bestellung getätigt wurde, traf es sich, dass es danach 2 Wochen lang kein weiterer Besucher und auch kein Bot mehr auf die Site schaffte. Die Bestell-Mail wurde daraufhin nicht verschickt! 2 Wochen lang nicht. Was soll ich sagen: der Verkauf kam nie zustande ... – also: keine Besucher, kein Cron.

Wer kein PHP-Experte ist und bei wem es nicht zu den guten Angewohnheiten gehört, vor Einsatz eines Moduls in den Quelltext zu schauen, der kann nie wissen, ob es in diesem Modul nicht eine Cron-Funktion gibt und er kann gleichfalls nicht wissen, ob diese nicht einen regelmäßigen Cron-Lauf erfordert. Ein Modul zur grafischen Anzeige der Entwicklung eines Aktienkurses, das darauf baut, dass exakt zu jeder Stunde der Wert geholt und gespeichert wird, würde wohl nicht gut funktionieren.

Schließlich: Poormanscron verträgt sich nicht mit dem aggressiven Caching-Modus Drupals. Auch hier würde bei Aktivierung desselben Cron niemals laufen.

Fazit

Fraglos verführt der Poormanscron: der Drupal-Admin steht auf vertrautem Boden: er weiß ganz einfach, wie ein Drupal-Modul installiert, aktiviert und konfiguriert wird. Und es soll ja auch immer schnell gehen. Das spricht für den Poormanscron, umso mehr, als man sich sonst dem Thema Cron vielleicht gar nicht erst zu stellen bereit ist.

Es liegt jedoch manchmal nur an einem Kickchen mehr an Knowhow, wenn nicht die beste der verfügbaren Möglichkeiten gewählt wird. Ein echter Cronjob dürfte ziemlich eindeutig die bessere Wahl sein und benötigt dabei nur gleich viel – wenn nicht sogar weniger – Zeit zu seiner Einrichtung als der Poormanscron.

Nicht zuletzt müßte ja der Armeleute-Cron als Einzelmodul gewartet, also geupdatet, mithin in Produktivumgebungen vor dem Einsatz getestet und überwacht werden und verschlänge somit potentiell auch in der Folge eine heute noch unabsehbare Zeit – eine Zeit, die wir alle nicht haben.

Weiterführende Links

Kommentare

JWD am 19. Dezember 2012 - 13:10 Uhr

Zum Glück geht das nun bei Drupal 7 etwas einfacher. Dennoch habe ich noch eine alte Seite entdeckt bei der ich diese Änderung benötigt habe!

Manu am 10. Februar 2011 - 18:19 Uhr

Vielen Dank erstmal!
Ja die Erfahrung mit Simplenews hatte ich leider auch. Aber dank dieses Videos wird dieses Problem bei mir nicht mehr auftauchen.

Besucher am 6. Juli 2010 - 13:18 Uhr

Übrigens Achtung!
Wenn das Modul Simplenews so konfiguriert ist, dass es bei jedem Cronaufruf z. B. 50 Mails verschickt, dann kommt es darauf an, wie oft Cron läuft, bis die Abonenntenliste abgearbeitet ist ... wir hatte bei uns ein Disaster, weil Cron nur einmal täglich lief und es an die 2000 Abonennten gab. Das Event war längst vorbei und es wurden immer noch Einladungen verschickt :(

Cheers.

Besucher am 16. Februar 2010 - 20:35 Uhr

thx

alexander am 11. September 2009 - 13:42 Uhr

Hi vielen Dank, jetzt habe ich das kapiert! und es klappt super!

Weiter so!

Mephisto Schuhe am 3. September 2009 - 11:00 Uhr

vielen Dank für das tolle Video, konnte so meine Cron Jobs ganz einfach einrichten.

Vertikalangeln am 31. August 2009 - 18:56 Uhr

Danke für die tollen Infos, waren mir eine sehr große Hilfe.

Hundefutter am 7. August 2009 - 14:26 Uhr

Das Video ist Toll, hab wieder mal etwas gelernt.

Danke für diese Infos!

Phil Veyton am 30. Juli 2009 - 11:52 Uhr

sehr tolles Tutorial, sowas habe ich gesucht. Bin aber bis dato immer gut mit poormanscron gefahren. Die Free Cronjob Anbieter sind auch nicht wirklich toll, deshalb werde ich das ganze jetzt mal auf diesem Weg versuchen.
viele Dank.

Fenix am 18. Juli 2009 - 11:58 Uhr

Ein sehr interessanter Artikel, aales wunderbar beschrieben, habe einiges dazugelernt. Das Video ist auch Toll!

Danke für diese INfos!

LR am 8. Juli 2009 - 10:52 Uhr

Hallo,

wirklich schönes Video. Kannte das alles schon, war aber wirklich äußerst angenehm, dieses Video anzusehen.

LG, Laura

HT am 30. Juni 2009 - 22:09 Uhr

Also das tutorial ist echt super. bin momentan dabei ein paar Cronjobs einzurichten. Hoffe es klappt alles.

Marc am 28. April 2009 - 13:32 Uhr

Einen Timeout durch Textausgabe kann man verhindern, wenn man am Ende des Cronjobs "&html_output=0" anhängt.
Beste Grüße

karl07 am 9. April 2009 - 9:22 Uhr

hi ludwig,
bin kein cron-experte, kann dir nur meine beobachtung bei der händischen ausführung von cron.php mitteilen, dass manchmal nicht alle aufgaben erledigt werden können und dann z.b. die meldung kommt, dass der search-index zu 88% indiziert wurde (oder so ähnlich). da muss man dann cron einfach mehrmals laufen lassen, bis alles erledigt ist.
du könntest probieren, die cron.php mehrmals händisch laufen zu lassen, bis z.b. jedenfalls der search-index vollständig indiziert ist. das kann man auf der seite admin/settings/search sehen, da gibt´s eine entsprechende zeile, die das mitteilt.
lg karl

ps: schließe mich dem allgemeinen lob an und freu mich außerdem, eine österreichische drupal-support-site gefunden zu haben. schöne grüße an frank und frohe ostern.

Fotograf am 4. April 2009 - 16:35 Uhr

Das ist mal eine gute Beschreibung der Crons.
Ich muss mal schauen, ob ich Timeouts umgehen kann, da bei mir der Cronjob um einiges länger dauert, als 30 Sekunden.

Gruß
Fotograf

Fabian am 31. März 2009 - 9:06 Uhr

...danke für die Beschreibung. Habe länger nach einer Cronjob Beschreibung gesucht - und das ganze auch noch als Videotutorial is natürlich "deluxe" ;-)

Ludwig am 7. März 2009 - 20:51 Uhr

Ich habe das jetzt anders gelöst. Wie das mit Windows aussieht, kann ich nicht sagen, aber Linux bringt da sehr gute Tools mit. Falls es jemand interessiert:
Wenn noch nicht vorhanden, Curl und GNOME Schedule (bei Gnome) installieren. Danach die oder den Job einrichten und schon ist alles automatisiert. Sicherlich gibt es auch noch weitere Möglichkeiten ...

Frank am 7. März 2009 - 20:33 Uhr

Drupal's cron.php gibt normalerweise eine weiße Seite aus - also nichts. Rufe die cron.php einmal im Webbrowser auf und schau Dir die (wahrscheinlichen) Fehlermeldungen an, wobei mir so ist, als würden nicht einmal Fehler zu einer Ausgabe irgendeiner Art führen. Was sagen denn die Logs? Cronläufe werden ja protokolliert...

Ludwig am 4. März 2009 - 15:05 Uhr

Leider funktioniert das bei mir nicht.

Ich habe zwei cronjobs für zwei Drupal Sites eigegeben.
Es kamen zwei Fehlermeldungen:
(zu lange)
(zu groß)

Mögliche Status-Meldungen:
erfolgreich: Der Cronjob wurde erfolgreich ausgeführt
zu lange: Die Cronjob-Ausführung wurde nach 30 Sekunden gestoppt
zu groß: Die Ausführung wurde abgebrochen, da die URL mehr als 1024 Bytes Daten ausgegeben hat
fehlerhaft: Der Cronjob konnte nicht ausgeführt werden (z.B. wegen fehlerhafter URL)

Hat jemand einen Rat?

Gruß Ludwig

lagerlogistik am 10. November 2008 - 20:55 Uhr

Sehr tolles Video-Tutorial! Ab einen "V-server" oder sogar Root Server kann selbständige Crons einrichten. Dann benötigt man keinen Freehoster anbieter!

Aber für eine kleine Homepage ist dies wunderbar!