(gelöst/Workaround) Cron, ein ewiges Leiden. Was tun?
Eingetragen von codeherr (73)am 26.09.2010 - 18:52 Uhr in
Ich weiß nicht, wie das bei anderen so ist. Ich habe mit Cron immer wieder Ärger. Kaum braucht ein Modul auch nur ein paar hundert Milisekunden (was sich in einem meiner Module dank etwas komplexeren Joins zur DB-Bereinigung nun mal nicht vermeiden läßt), wird das vom System als "hängt sehr wahrscheinlich" gewertet und dementsprechend schaukelt sich das Ding hoch ("versuche Cron erneut zu starten" usw. usf.), bis dann jeder Durchlauf mit "fehlgeschlagen" endet und effektiv überhaupt nicht mehr gecront wird.
Ich persönlich halte die ganze Architektur (zumindest so wie ich sie in D6 finde) für ziemlich wackelig und inakzeptabel, schon alleine, wenn ein einzelnes Modul aus welchem Grund auch immer das gesamte Konstrukt deadlocken kann. Und der einzige, der - wenn man mal die Suchmaschinen bemüht - damit seine liebe Not hat, bin ich ja nun weiß Gott nicht. Daß tägliches "reagieren" in Form von "mal eben eine Zeile aus der Variablentabelle löschen und in Common.inc was auskommentieren, dann laufen lassen und wieder zurückändern" keine seriöse Dauerlösung sein können, wird sicher niemand bestreiten wollen...
Das alles nur als meine Einschätzung, die ich nur vorwegschicken wollte, und die an sich schon feststeht und nicht teil meiner Frage sein soll.
Interessieren würden mich aber umso mehr andere Meinungen zu...
1.) Lösungsansatz
Dauerhafte Änderung der "common.inc", wo der Abschnitt
// Fetch the cron semaphore
$semaphore = variable_get('cron_semaphore', FALSE);durch
// Fetch the cron semaphore
#$semaphore = variable_get('cron_semaphore', FALSE);
$semaphore = FALSE; nicht wie in den bekannten Workarounds temporär sondern einfach dauerhaft geändert bleibt. Ja, das muß man dann bei jedem Update erneut implementieren. Gibt es irgendetwas, das dagegen spricht, solange man sich halbwegs auf die Intaktheit seiner cron implementierenden Module verlassen kann? Im schlimmsten Falle läuft dann eben "mal" ein Cronjob parallel zu einem anderen. Ist das dramatisch?
oder aber
2.) Ansatz
Einfach für entweder die eigenen oder aber gleich alle Module ein verbessertes Cron-"Modul"/-System basteln, das wie auch immer, die fehleranfälligen Ansätze des Originals nicht verfolgt, sprich, evtl sogar jeden einzelnen Modul-cron-hook als unabhängigen Subprozeß lostritt. Ob letztlich mein Cronjob "/cron.php" oder aber "/sites/all/modules/my_better_cron/cron.php" aufruft, ist ja im Grunde egal.
oder schließlich
3.) Ansatz
Es hatte schon jemand die gleiche Idee wie in 2. und ich hab sie nur noch nicht gefunden ;) Weiß da jemand was?
- Anmelden oder Registrieren um Kommentare zu schreiben
Das halte ic für den falschen Ansatz
am 27.09.2010 - 14:51 Uhr
Hallo,
meiner Meinung nach ist das der falsche Ansatz. Ich würde forschen, warum cron fehlschlägt.
- set_time_limit in php.ini prüfen;
- Module identifizieren, die besonders lange für cron brauchen (ich hatte dazu die Zeiten in module_invoke_all für cron mitgeloggt, bis ich den Übeltäter gefunden hatte);
- @set_time_limit(240) in drupal_cron_run() evtl. anpassen.
Bei mir laufen eine Menge cron-Aufgaben ohne Probleme :)
tower schrieb meiner Meinung
am 27.09.2010 - 15:14 Uhr
meiner Meinung nach ist das der falsche Ansatz. Ich würde forschen, warum cron fehlschlägt.
Welchen der drei meinst Du denn?
- set_time_limit in php.ini prüfen;
Diesen Wert gibt es in meiner PHP.ini nicht, aber du meinst vlt. max_execution_time? War bis auf 480sek. aber scheint mir irrelevant, da auch bei manuellem Cron der Abbruch sofort kam und die betreffende Join-Abfrage nach verschiedenen Messungen selbst im Extremfall maximal 2 Sekunden schluckte...
Aber selbst wenn in meinem Modul ein Fehler ist/wäre: Findest Du denn nicht, daß so ein wichtiges Ding wie Cron sich dennoch niemals an einem solchen Fehler komplett aufhängen dürfte? Eine Warnung werfen, ok. Das entspr. Modul im weiteren Verlauf ignorieren, ok. Aber komplett abdanken? Bei so vielen Modulen wie es gibt, kann man doch nicht permanent aufpassen, daß alles gut geht?!?! Also ich jedenfalls nicht...
(ich hatte dazu die Zeiten in module_invoke_all für cron mitgeloggt, bis ich den Übeltäter gefunden hatte);
Naja klaro, und der "Übeltäter" war in dem Fall mein Modul. Nur: Nachdem ich Ansatz 1 vorerst als Workaround einsetze, funktioniert es ja nun schon tagelang, was doch eigentlich klarmacht, daß es kein grundlegender Codefehler ist, sondern eher eine problematische Konvention die irgendwo liegt. So toll Drupal ist, es ist ja von Menschen gemacht die auch nicht sofort jede Etwaigkeit bedacht haben ;)
@set_time_limit(240) in drupal_cron_run() evtl. anpassen.
240 klingt nach vier Minuten, in dem Fall siehe oben...oder für was ist diese Einstellung? (Und: Wo?)
Bei mir laufen eine Menge cron-Aufgaben ohne Probleme :)
Schon klar, einen erwischt's halt immer und den anderen nie ;) Aber ich bin ja wie gesagt beiweitem nicht der einzige...
ich hab grad bei einer
am 27.09.2010 - 15:20 Uhr
ich hab grad bei einer openatrium installation probleme mit dem cron job gehabt, deswegen kann ich dir zustimmen: das standard module ist etwas blöd zu handhaben, wenn denn mal probleme mit dem cron job auftauchen.
jedenfalls habe ich dann diese zwei module gefunden, und mit dem einen - supercron - habe ich schnell meinen fehler beheben können. das zweite modul macht ähnliches, also wäre vielleicht auch eine alternative.
1_supercron: http://drupal.org/project/supercron
2_elysia_cron: http://drupal.org/project/elysia_cron
grüße,
walter
Danke!
am 27.09.2010 - 15:26 Uhr
War ja klar, daß bei den vielen Klagen über core-cron längst jemand das Rad neu erfunden hat. [del]Supercron klingt[/del][ins]beide klingen[/ins] ja ziemlich genau nach Ansatz 2/3. Ich werde das umgehend testen und sage herzlichen Dank für den Tip :-)
update-Modul
am 16.03.2011 - 01:20 Uhr
Ich hatte vergessen, das hier auch zu posten: Seit ich das "Update"-Modul (core) deaktiviert habe, nachdem es woanders als beliebte Ursache benannt wurde, ist das Problem erledigt. Nun muß ich eben ab und zu von Hand nach Updates schauen, aber damit kann ich leben.
Hintergrund: Offenbar gibt es - unter bestimmten Konfigurationen - Verbindungsprobleme mit dem Updateserver. Ich konnte die nicht lösen. Drum der Behelf, ist wie gesagt für mich ok.