Empêcher l'exécution concurrente d'un script d'administration : flock, lockf et mutex nommé sous Windows

Objectif

Garantir qu'une seule instance d'un script d'administration s'exécute à la fois, et qu'une exécution précédente interrompue brutalement ne bloque pas définitivement les suivantes.

Prérequis

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

Étapes

1. Sous Linux, deux options : soit encapsuler la commande, flock -n -E 75 /var/lock/my-admin-script.lock /usr/local/bin/my-admin-script.sh (sans -E, un conflit de verrou et un échec du script renvoient tous deux 1 et ne peuvent pas être distingués), soit prendre le verrou dans le script, sur un descripteur de fichier : exec 9>/var/lock/my-admin-script.lock; flock -n 9 || { echo "already running"; exit 75; }. flock(1), présenté dans sa documentation comme un utilitaire pour "manage locks from shell scripts" (gérer des verrous depuis des scripts shell), lie le verrou à un descripteur de fichier ouvert : il est donc libéré automatiquement dès que le dernier processus détenant ce descripteur se termine ou est tué. Contrairement à un fichier PID oublié, il ne peut pas devenir obsolète. Les processus enfants héritent du descripteur : un démon lancé depuis le script verrouillé conserve le verrou jusqu'à sa propre fin, sauf s'il est démarré avec 9>&-.
2. Utiliser -n/--nonblocking pour échouer immédiatement si une autre instance détient déjà le verrou (adapté à une tâche planifiée qui doit sauter une exécution en chevauchement), ou -w <seconds> pour attendre jusqu'à un délai maximal.
3. Sous FreeBSD, l'équivalent est lockf -k -t 0 /var/run/my-admin-script.lock /usr/local/bin/my-admin-script.sh ; lockf(1) est décrit comme un utilitaire qui "acquires an exclusive lock" (acquiert un verrou exclusif) sur un fichier, le crée si nécessaire, exécute la commande donnée tant qu'il détient le verrou, puis le libère à la fin de la commande. Sans -k, il supprime le fichier de verrou à la sortie ; un conflit de verrou se termine avec le code 75 (EX_TEMPFAIL).
4. Sous Windows, utiliser un mutex nommé, valable pour tout le système, plutôt qu'un fichier de verrou : $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() }. Si le détenteur précédent est mort, l'appel suivant à WaitOne lève AbandonedMutexException tout en accordant la propriété du mutex, d'où le catch. La documentation .NET distingue les mutex anonymes, locaux au processus, des "named system mutexes" (mutex système nommés), visibles entre processus ; le préfixe Global\ fait en sorte que le nom couvre toutes les sessions utilisateur.
5. Toujours libérer le verrou ou le mutex dans un bloc finally/trap, afin qu'une exception levée dans le corps du script le libère quand même ; ne pas se reposer uniquement sur le chemin de sortie normal.
6. Journaliser distinctement les deux issues : "skipped, another instance is running" n'est pas le même événement que "started", et l'outil qui supervise la planification ne doit pas le traiter comme un échec.

Résultat attendu

Si le script est lancé une seconde fois alors que la première instance tourne encore, il se termine immédiatement (ou attend, selon le mode choisi) au lieu d'exécuter les deux copies sur le même état ; tuer le processus de la première exécution libère le verrou sans nettoyage manuel.

Limites et base de vérification

Le verrouillage consultatif de flock n'arrête que les autres processus qui passent eux aussi par flock/flock(2) : il n'empêche pas un processus qui ignore le verrou de modifier directement les mêmes fichiers. Sur un système de fichiers réseau (NFS), les fichiers de verrou peuvent ne pas appliquer la sémantique de flock de façon cohérente entre les hôtes ; pour une garantie sur un seul hôte, conserver le fichier de verrou sur un stockage local. Un mutex nommé créé par un compte peut être inaccessible (accès refusé) à un script exécuté sous un autre compte ; exécuter toutes les instances sous le même compte ou accorder explicitement l'accès.