Parallele Ausführung eines Admin-Skripts verhindern: flock, lockf und ein benannter Mutex unter Windows

Ziel

Sicherstellen, dass nur eine Instanz eines Admin-Skripts gleichzeitig läuft und dass ein abgestürzter früherer Lauf künftige Läufe nicht dauerhaft blockiert.

Voraussetzungen

flock (util-linux) unter Linux; lockf unter FreeBSD; PowerShell 5.1 oder 7.x unter Windows.

Schritte

1. Unter Linux entweder den Befehl umschliessen, flock -n -E 75 /var/lock/my-admin-script.lock /usr/local/bin/my-admin-script.sh (ohne -E liefern ein Sperrkonflikt und ein Skriptfehler beide den Rückgabewert 1 und lassen sich nicht voneinander unterscheiden), oder die Sperre im Skript über einen Dateideskriptor setzen: exec 9>/var/lock/my-admin-script.lock; flock -n 9 || { echo "already running"; exit 75; }. flock(1), laut Dokumentation ein Werkzeug zum "manage locks from shell scripts", bindet die Sperre an einen offenen Dateideskriptor. Sie wird daher automatisch freigegeben, sobald der letzte Prozess, der diesen Deskriptor hält, beendet oder abgebrochen wird; anders als eine liegengebliebene PID-Datei kann sie nicht veralten. Kindprozesse erben den Deskriptor: Ein Daemon, der aus dem gesperrten Skript gestartet wird, behält die Sperre bis zu seinem Ende, ausser er wird mit 9>&- gestartet.
2. Mit -n/--nonblocking schlägt der Aufruf sofort fehl, wenn bereits eine andere Instanz die Sperre hält (richtig für einen geplanten Job, der einen überlappenden Lauf auslassen soll). Alternativ wartet -w <seconds> bis zu einem Timeout.
3. Unter FreeBSD lautet die Entsprechung lockf -k -t 0 /var/run/my-admin-script.lock /usr/local/bin/my-admin-script.sh. lockf(1) ist dokumentiert als Werkzeug, das auf einer Datei "acquires an exclusive lock", die Datei bei Bedarf anlegt, den angegebenen Befehl unter dieser Sperre ausführt und die Sperre freigibt, sobald der Befehl beendet ist. Ohne -k wird die Sperrdatei beim Beenden gelöscht; ein Sperrkonflikt beendet den Aufruf mit 75 (EX_TEMPFAIL).
4. Unter Windows statt einer Sperrdatei einen benannten, systemweiten Mutex verwenden: $mutex = New-Object System.Threading.Mutex($false, "Global\MyAdminScript"); try { $got = $mutex.WaitOne(0) } catch [System.Threading.AbandonedMutexException] { $got = $true }; if (-not $got) { Write-Error "already running"; exit 75 }; try { <script body> } finally { $mutex.ReleaseMutex(); $mutex.Dispose() }. Ist der vorherige Besitzer abgestürzt, wirft das nächste WaitOne eine AbandonedMutexException, gewährt aber trotzdem den Besitz; daher das catch. Die .NET-Dokumentation unterscheidet unbenannte, prozesslokale Mutexe von "named system mutexes", die prozessübergreifend sichtbar sind; mit dem Präfix Global\ gilt der Name für alle Benutzersitzungen.
5. Die Sperre bzw. den Mutex immer in einem finally- oder trap-Block freigeben, damit sie auch bei einer Exception im Skriptkörper freigegeben wird; sich nicht allein auf den normalen Beendigungspfad verlassen.
6. Beide Ausgänge getrennt protokollieren: "skipped, another instance is running" ist nicht dasselbe Ereignis wie "started" und sollte von der Überwachung des Zeitplans, welcher Art auch immer, nicht als Fehler gewertet werden.

Erwartetes Ergebnis

Wird das Skript ein zweites Mal gestartet, während das erste noch läuft, beendet es sich sofort (oder wartet, je nach gewähltem Modus), statt beide Kopien auf demselben Zustand arbeiten zu lassen. Wird der Prozess des ersten Laufs abgebrochen, wird die Sperre ohne manuelles Aufräumen freigegeben.

Grenzen und Prüfbasis

Das Advisory Locking von flock hält nur andere Prozesse auf, die ebenfalls flock/flock(2) verwenden; ein Prozess, der die Sperre ignoriert und dieselben Dateien direkt bearbeitet, wird nicht gestoppt. Sperrdateien auf einem Netzwerkdateisystem (NFS) setzen die flock-Semantik unter Umständen nicht konsistent über mehrere Hosts hinweg durch; für eine Garantie auf einem einzelnen Host die Sperrdatei auf lokalem Speicher ablegen. Ein benannter Mutex, der von einem Konto erstellt wurde, kann für ein Skript unter einem anderen Konto unzugänglich sein (Zugriff verweigert); daher alle Instanzen unter demselben Konto ausführen oder den Zugriff ausdrücklich freigeben.