Evitar ejecuciones simultáneas de un script de administración: flock, lockf y un mutex con nombre en Windows

Objetivo

Asegurar que solo una instancia de un script de administración se ejecute a la vez y que una ejecución anterior que haya fallado no bloquee de forma permanente las siguientes.

Requisitos previos

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

Pasos

1. En Linux, se puede envolver el comando con flock -n -E 75 /var/lock/my-admin-script.lock /usr/local/bin/my-admin-script.sh (sin -E, un conflicto de bloqueo y un fallo del script devuelven ambos 1 y no se pueden distinguir), o bien tomar el bloqueo dentro del script sobre un descriptor de archivo: exec 9>/var/lock/my-admin-script.lock; flock -n 9 || { echo "already running"; exit 75; }. flock(1), documentado como una utilidad para "manage locks from shell scripts" (gestionar bloqueos desde scripts de shell), asocia el bloqueo a un descriptor de archivo abierto, de modo que se libera automáticamente cuando el último proceso que mantiene ese descriptor termina o es eliminado; a diferencia de un archivo PID residual, no puede quedar obsoleto. Los procesos hijos heredan el descriptor: un demonio iniciado desde el script bloqueado conserva el bloqueo hasta que termina, a menos que se inicie con 9>&-.
2. Se usa -n/--nonblocking para que falle de inmediato si otra instancia ya tiene el bloqueo (lo adecuado para una tarea programada que debe omitir una ejecución solapada), o -w <seconds> para esperar hasta un tiempo máximo.
3. En FreeBSD, el equivalente es lockf -k -t 0 /var/run/my-admin-script.lock /usr/local/bin/my-admin-script.sh; lockf(1) está documentado como una utilidad que "acquires an exclusive lock" (adquiere un bloqueo exclusivo) sobre un archivo, creándolo si es necesario, ejecuta el comando indicado mientras lo mantiene y libera el bloqueo cuando el comando termina. Sin -k elimina el archivo de bloqueo al salir; un conflicto de bloqueo termina con el código 75 (EX_TEMPFAIL).
4. En Windows, se usa un mutex con nombre de ámbito global del sistema en lugar de un archivo de bloqueo: $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 el poseedor anterior murió, el siguiente WaitOne lanza AbandonedMutexException pero concede la propiedad; de ahí el catch. La documentación de .NET distingue los mutex sin nombre, locales al proceso, de los "named system mutexes" (mutex de sistema con nombre), visibles entre procesos; el prefijo Global\ hace que el nombre abarque todas las sesiones de usuario.
5. Hay que liberar siempre el bloqueo o el mutex en un bloque finally/trap, para que una excepción durante el cuerpo del script también lo libere; no conviene depender solo de la ruta de salida normal.
6. Se deben registrar ambos resultados de forma distinta: "skipped, another instance is running" (omitido, hay otra instancia en ejecución) no es el mismo evento que "started" (iniciado), y quien supervise la programación no debería tratarlo como un fallo.

Resultado esperado

Al iniciar el script por segunda vez mientras la primera ejecución sigue en curso, este termina de inmediato (o espera, según el modo elegido) en lugar de ejecutar ambas copias sobre el mismo estado; al matar el proceso de la primera ejecución, el bloqueo se libera sin limpieza manual.

Límites y base de verificación

El bloqueo consultivo de flock solo detiene a otros procesos que también pasan por flock/flock(2); no detiene a un proceso que ignore el bloqueo y edite directamente los mismos archivos. Los archivos de bloqueo en un sistema de archivos de red (NFS) pueden no aplicar de forma coherente la semántica de flock entre distintos hosts; para una garantía en un solo host, el archivo de bloqueo debe estar en almacenamiento local. Un mutex con nombre creado por una cuenta puede ser inaccesible (acceso denegado) para un script que se ejecute con otra cuenta; hay que ejecutar todas las instancias con la misma cuenta o conceder el acceso de forma explícita.