fix(PROJ-58): Lockfile gegen überlappende Cron-Batch-Läufe + update.sh synct Cron-Dateien

Root Cause für ausbleibende Lastsenkung: update.sh hat /etc/cron.d/archivmail
nie auf den Server kopiert, daher fehlten die PROJ-58-Cronzeilen trotz
aktivem batch_mode komplett. Jetzt kopiert update.sh die Cron-Datei und alle
Wrapper-Skripte bei jedem Deploy automatisch ein.

Zusätzlich: Wrapper-Skripte (analog mailpiler indexer.delta.sh) verhindern
per Lockfile, dass sich Cron-Läufe bei großem Backlog überlappen.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
sysops
2026-06-24 23:54:37 +02:00
co-authored by Claude Sonnet 4.6
parent c91eeac0a0
commit 46502abe75
5 changed files with 70 additions and 2 deletions
+6
View File
@@ -59,6 +59,12 @@ Aktuell laufen Indexierung (`internal/index/tenant_worker.go`) und OCR (`interna
- Minor-Finding behoben: `index-pending` fehlte in `printHelp()` (cmd_import.go) — ergänzt.
- Keine Critical/High-Findings. Server 192.168.1.131 nicht angefasst während der QA.
## Nachtrag (2026-06-24): Lockfile-Schutz gegen überlappende Cron-Läufe
Nutzer wies auf mailpiler-Vorbild hin (`indexer.delta.sh`, PID-Lockfile-Muster), um zu verhindern, dass sich Cron-Läufe bei großem Backlog überlappen (würde die Last-Glättung wieder aufheben). Umgesetzt:
- Neue Wrapper-Skripte `deploy/cron.d/archivmail-index-pending.sh` und `deploy/cron.d/archivmail-ocr-reprocess.sh` — Lockfile unter `/var/run/archivmail/*.lock`, analog zu Pilers `MAINTMPFILE`/`DELTATMPFILE`-Muster (Datei mit Zeitstempel statt PID, da `trap ... EXIT` zuverlässig aufräumt; bei bereits laufendem Lauf wird einfach übersprungen statt zu warten/abzubrechen mit Fehlercode, damit Cron keine Fehlermail wegen "schon belegt" verschickt).
- `deploy/cron.d/archivmail` ruft jetzt die Wrapper-Skripte unter `/usr/local/bin/` auf statt das Binary direkt.
- **Root Cause für "Last geht nicht runter" gefunden:** `update.sh` synct `/etc/cron.d/archivmail` nie auf den Server — die PROJ-58-Cronzeilen fehlten auf 131 UND 132 komplett, obwohl `batch_mode` im Code bereits aktiv war. Daher lief weiterhin nichts batch-weise, weil der Backlog nie per Cron abgeholt wurde. Fix: `update.sh` kopiert jetzt `deploy/cron.d/archivmail` nach `/etc/cron.d/archivmail` und alle `deploy/cron.d/*.sh`-Wrapper nach `/usr/local/bin/` bei jedem Deploy.
## Nachtrag (2026-06-24): batch_mode als Default für Neuinstallationen
Auf Nutzerwunsch ist `index.batch_mode: true` und `ocr.batch_mode: true` jetzt aktiv (nicht mehr auskommentiert) in `config/config.docker.yml.example` gesetzt, damit neue Installationen direkt mit Cron-Batch statt Dauerbetrieb starten. Bestehende Installationen (wie 192.168.1.131/132) sind davon nicht betroffen, da deren `/etc/archivmail/config.yml` unabhängig vom Repo-Beispiel ist und weiterhin ohne `batch_mode`-Einträge (= Dauerbetrieb) läuft.