Zwei Cronjobs, ein Repository und drei Wochen Stillstand

Ein Cronjob, also ein zeitgesteuerter Programmlauf, führte gleichzeitig mit einem zweiten Lauf einen git pull am selben Git-Repository aus. Die parallelen Befehle schrieben FETCH_HEAD doppelt und brachen mit «fatal: Cannot rebase onto multiple branches» ab. Seit ich jeden Git-Schritt mit flock, einem Linux-Werkzeug für Prozesssperren, über eine Sperrdatei führe, sind die Zugriffe geordnet.

Der Stillstand blieb lange verborgen

Vom 8. September bis 2. Oktober 2026 erschien in meinen Notizen kein neuer Beitrag, obwohl ich Entwürfe freigab. Der Stillstand blieb drei Wochen unbemerkt, weil der Morgencheck nur ein Problem meldete und keine Ursache nannte.

Die Fehlermeldung wies auf Git. Seit dem 22. September brachen der Schreiblauf und der Poller an jedem Werktag ab. Beide waren über Cron auf 07:00 Uhr angesetzt und griffen in derselben Sekunde auf das Repository zu.

Drei Ursachen lagen übereinander

Der Poller, also der Lauf zur Prüfung der Entwürfe, las mit head -1 nur den ältesten Eintrag. Ein unbeantworteter Entwurf vom 9. September blieb dadurch an erster Stelle. Er blockierte alle späteren Entwürfe, darunter meine Freigaben vom 29. und 30. September.

Dazu kam die Kollision im Repository. Zwei parallele git pull bearbeiteten FETCH_HEAD gleichzeitig. Beide Läufe endeten mit derselben Meldung und erreichten ihre weiteren Schritte nicht.

Eine Prüfregel für die Startseite bildete die dritte Ursache. Sie stoppte ein Wort aus einem Beitragstitel. Damit lagen ein blockierter Poller, ein gleichzeitiger Git-Zugriff und eine Inhaltsprüfung im selben Ablauf.

Der Nachbau zeigte die Kollision

Am 2. Oktober 2026 stellte ich den Fehler nach. Ohne Sperre scheiterten 5 von 5 Paaren paralleler Git-Läufe. Mit flock scheiterten 0 von 5 Paaren.

Damit war der zeitgleiche Zugriff als Ursache reproduzierbar. Beim LOGBUCH hatte ich die Laufzeiten bereits im Juli um ein bis zwei Minuten versetzt. Der Notizen-Lauf und der Notizen-Poller standen weiterhin beide auf 07:00 Uhr.

Eine Sperrdatei ordnet die Zugriffe

Seither läuft jeder Git-Schritt hinter flock -w 120 auf einer Sperrdatei. flock wartet dabei bis zu 120 Sekunden auf die Sperre. Die Funktionsweise und die Optionen sind in der flock(1), Linux-Handbuchseite beschrieben.

Die Sperre sitzt in den Startern und in den Skripten. Die Starter liegen ausserhalb des Repositorys. Das ist wichtig, weil Bash ein laufendes Skript stückweise nachliest. Ein git pull auf das eigene Skript könnte den Inhalt während des Laufs verändern und Bash an einer falschen Stelle weiterlaufen lassen.

Der Poller prüft nun alle Entwürfe. Die Abläufe gehören zum Projekt, das ich auf der Projektseite Hermes beschreibe.

Nebenbei fand ich 13 nie freigegebene Entwurfsseiten, die öffentlich erreichbar waren. Das Vorschau-HTML war liegen geblieben und gelangte mit der nächsten Veröffentlichung ins Netz. Seit dem 2. Oktober 2026 löschen die Generatoren jede Beitragsseite, für die keine Markdown-Quelle vorhanden ist.

Was ich daraus mitnehme

Ich nehme aus dem Ausfall mit, dass ein gemeinsamer Zeitplan bei Git eine gemeinsame Schreibstelle erzeugen kann. Die Nachstellung mit den Testpaaren machte die Kollision sichtbar und überprüfte die Sperre. Der Morgencheck zeigte mir zudem, dass eine Problemmeldung ohne Ursache einen Stillstand lange verdecken kann.

---

Modell dieser Notiz: gpt-5.6-sol.