Warum ein Scheduled Task nicht läuft
Der Zustand skipped blockiert nichts — der Scheduler nimmt solche Aufgaben mit. Wirklich fest hängt eine Aufgabe in running, und dann zwölf Stunden lang.
„Der Task läuft nicht." Fast immer folgt darauf ein Blick ins Log, und das ist der zweitbeste Ort. Der beste ist die Tabelle, in der Shopware den Zustand jeder geplanten Aufgabe festhält.
Die Zustände, und was sie bedeuten
Aus einer laufenden Installation:
| Zustand | Anzahl |
|---|---|
scheduled | 31 |
skipped | 2 |
Die zwei übersprungenen sind shopware.elasticsearch.create.alias und
telemetry.collect_periodic_metrics — beide, weil die zugehörige Funktion in
dieser Installation nicht aktiv ist.
Und hier liegt das erste Missverständnis: skipped sieht nach einem Problem
aus und ist keines. Der Scheduler wählt Aufgaben in beiden Zuständen aus:
new EqualsAnyFilter('status', [
ScheduledTaskDefinition::STATUS_SCHEDULED,
ScheduledTaskDefinition::STATUS_SKIPPED,
]),
Eine übersprungene Aufgabe wird also beim nächsten Durchlauf wieder berücksichtigt. Sie ist nicht abgeschaltet, sie hatte beim letzten Mal nichts zu tun.
Der Zustand, der wirklich blockiert
Direkt darunter steht im Kern die eigentliche Antwort:
// requeue tasks that are stuck in "running" or "queued" state for more than 12 hours
// we assume that either the message was lost or the worker crashed
Zwölf Stunden. Eine Aufgabe, die in running oder queued hängenbleibt —
weil der Worker abgestürzt ist, der Container neu gestartet wurde oder die
Nachricht verlorenging —, wird erst nach einem halben Tag wieder eingereiht.
Für eine Aufgabe mit einem Intervall von einer Minute heißt das: 720 ausgefallene Durchläufe, bevor sich das System selbst hilft. Für die Sitemap-Erzeugung ist das verkraftbar. Für eine Aufgabe, an der ein Bestandsabgleich hängt, nicht.
Die Prüfung, die drei Sekunden dauert
| Was Sie sehen | Was es bedeutet |
|---|---|
Zustand scheduled, next_execution_time in der Zukunft | alles in Ordnung, die Aufgabe wartet |
Zustand scheduled, next_execution_time lange vorbei | niemand holt sie ab — es läuft kein Worker |
Zustand running seit Stunden | hängt fest — der Kern greift erst nach zwölf Stunden ein |
Zustand queued seit Stunden | dasselbe: die Nachricht wurde erzeugt und nie verarbeitet |
Zustand skipped | unauffällig, die Funktion dahinter ist aus |
Zustand failed | die Aufgabe ist gelaufen und gescheitert — jetzt lohnt das Log |
Erst die letzte Zeile ist ein Fall für das Log. Die fünf Zeilen darüber sind es nicht — dort steht die Antwort schon in der Tabelle.
Die Intervalle
| kürzestes Intervall | 60 s |
| längstes Intervall | 2.628.000 s (30 Tage) |
| Aufgaben mit abweichendem Intervall | 0 von 33 |
Dass keine einzige Aufgabe von ihrem Standardintervall abweicht, ist der Auslieferungszustand. In gewachsenen Shops steht hier regelmäßig etwas Verstelltes — und ein Intervall, das jemand vor zwei Jahren auf einen Tag gesetzt hat, ist eine plausible Erklärung dafür, dass „nichts passiert".
Wichtig dabei: Das Intervall ist eine Angabe für die Einplanung, keine Zusage über die Ausführung. Ob eine Aufgabe mit einem Minutenintervall auch jede Minute läuft, hängt allein daran, wie oft ein Worker nachsieht.
Grenzen dieser Messung
Es wurde kein Worker-Lauf beobachtet und kein Absturz provoziert. Die Aussage über die zwölf Stunden stammt aus der Auswahlbedingung im Kern, die Aussage über die Zustände aus dem Tabelleninhalt.
Nicht gemessen wurde, wie sich eine Installation mit mehreren parallelen Workern verhält, und ebenso wenig das Zusammenspiel mit dem Admin-Worker, der in Entwicklungsumgebungen die Aufgaben aus dem Browser heraus anstößt. Beide Fälle können das Bild verschieben.
Die Zahlen stammen aus einer 6.7.13.1 mit neun Plugins. Zwei der 33 Aufgaben kommen aus Erweiterungen; in einem anderen Shop sind es andere.
Häufige Fragen
- Was bedeutet der Zustand skipped?
- Dass die Aufgabe beim letzten Durchlauf übersprungen wurde, meist weil die zugehörige Funktion aus ist. Sie ist damit nicht blockiert — der Scheduler wählt Aufgaben im Zustand scheduled und skipped gleichermaßen aus.
- Welcher Zustand blockiert wirklich?
- running und queued. Eine Aufgabe, die dort hängenbleibt — etwa weil der Worker abgestürzt ist —, wird vom Kern erst nach zwölf Stunden wieder eingereiht.
- Woran erkenne ich, dass gar kein Worker läuft?
- Daran, dass next_execution_time in der Vergangenheit liegt und sich nicht bewegt. Der Zeitpunkt wird beim Einplanen gesetzt; bleibt er stehen, hat niemand die Aufgabe abgeholt.
- Wie kurz kann ein Intervall sein?
- Der kürzeste im Kern ausgelieferte Wert sind 60 Sekunden. Das ist eine Mindestangabe für die Einplanung, keine Zusage über die tatsächliche Ausführung — die hängt am Worker.