Regelmäßige Aufgaben¶

Wiederkehrende Aufgaben laufen als Zeitpläne im Worker (Dienst worker), nicht mehr per Crontab auf dem Host. Die Zeitpläne stehen im Code und sind damit in jeder Installationsart gleich: ein Server mit Docker Compose, mehrere Server oder Kubernetes. Läuft kein Worker, laufen auch keine Zeitpläne; die Anwendung meldet das (siehe Überwachung).

So arbeiten die Zeitpläne:

• Der Worker legt je Termin genau einen Auftrag an, auch wenn mehrere Worker laufen.
• Zeiten gelten in der Zeitzone der Anwendung (Europe/Berlin).
• Ein verpasster Termin, etwa während eines Updates, wird in der Regel einmal nachgeholt. Ein neuer Zeitplan beginnt mit seinem nächsten Termin.
• Verwaltungsbefehle laufen wie früher der Cron-Eintrag als eigener Prozess im Worker-Container, mit Sperre gegen parallele Läufe und fester Zeitgrenze. Ein gescheiterter Lauf wird nicht wiederholt; der nächste Termin ist die Wiederholung. Er erscheint im Admin unter „Aufträge“ und in der Metrik mandari_tasks_dead.
• Die Ausgabe steht im Protokoll des Workers: docker compose logs worker.

Zeitpläne mit Verwaltungsbefehlen¶

Weitere Zeitpläne¶

Die aktuelle Liste mit dem zuletzt geplanten Termin zeigt:

docker compose exec worker python manage.py events_scheduler --list

Von Hand ausführen¶

Ein Verwaltungsbefehl, den ein Zeitplan bedient, endet beim Aufruf von Hand mit dem Hinweis „läuft als Zeitplan im Worker – Aufruf übersprungen“ (Exit-Code 0). So entstehen keine Doppelläufe. Einen echten Lauf erzwingt --trotz-zeitplan:

docker compose exec worker python manage.py cache_files --trotz-zeitplan

Aufrufe, die nur lesen oder berichten, laufen immer: --dry-run, check_source_health --report, check_service_levels --report, cache_files --stats, loeschabgleich --robots, dokumentablage ohne Schritt und availability_report ohne --out.

Einzelne Zeitpläne abschalten¶

EVENTS_SCHEDULES_DISABLED nimmt die Namen kommagetrennt auf, zum Beispiel EVENTS_SCHEDULES_DISABLED=befehl:build_meeting_packages. Danach Worker und Anwendung neu starten (docker compose up -d worker mandari). Die Termine verstreichen dann ohne Auftrag; wird der Zeitplan wieder eingeschaltet, geht es mit dem nächsten Termin weiter, nichts wird nachgeholt.

Was auf dem Host bleibt¶

In der Crontab des Hosts stehen nur noch Aufgaben des Betriebssystems:

• die Datensicherung mit ./backup.sh, die der Installer täglich um 02:00 einträgt (siehe Updates und Backups),
• bei einer Sicherung mit restic deren Überwachung (backup-watchdog.sh),
• auf Wunsch der Neustart ungesunder Container (deploy/scripts/restart-unhealthy.sh) und der Alarm aus dem Systemjournal (deploy/logging/journal-alert.sh).

Steht danach noch ein manage.py-Aufruf in der Crontab, gehört er als Zeitplan in den Code.

Umstellung von einer bestehenden Crontab¶

Ältere Installationen hatten die Verwaltungsbefehle in der Crontab des Hosts. Die Umstellung läuft ohne Doppelläufe und ohne Lücke:

1. Worker prüfen: docker compose ps worker zeigt healthy, /health/ meldet "worker": "ok".

2. Update einspielen. Ab jetzt planen die Zeitpläne. Ein noch vorhandener Cron-Eintrag erkennt den Worker und endet mit „Aufruf übersprungen“; läuft kein Worker, arbeitet er wie bisher. Kontrolle nach einem Tag:

   grep -h "Aufruf übersprungen" /var/log/mandari-*.log | tail
   docker compose logs --since 24h worker | grep "Zeitplan befehl:"
   

3. Crontab bereinigen: erst sichern (crontab -l > ~/crontab-vorher.txt), dann die Zeilen der Verwaltungsbefehle entfernen.

4. Rückweg: einzelne Zeitpläne mit EVENTS_SCHEDULES_DISABLED abschalten und den gesicherten Cron-Eintrag wieder eintragen.

Überwachung¶

Braucht die Installation einen Worker (Standard, wegen der Zeitpläne) und läuft keiner, melden /health/ und /health/ready/ „degraded“, und Admin-Startseite und Betriebsmonitor zeigen den Hinweis „Worker“. Die Anwendung bleibt dabei in Betrieb. Wer den Worker an eine Statusseite melden will, setzt WORKER_PUSH_URL (siehe Konfiguration).