Preventing concurrent runs of an admin script: flock, lockf and a named mutex on Windows

Goal

Ensure only one instance of an admin script runs at a time, and that a crashed previous run does not permanently block future ones.

Prerequisites

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

Steps

1. On Linux, either wrap the command, flock -n -E 75 /var/lock/my-admin-script.lock /usr/local/bin/my-admin-script.sh (without -E, a lock conflict and a script failure both return 1 and cannot be told apart), or take the lock inside the script on a file descriptor: exec 9>/var/lock/my-admin-script.lock; flock -n 9 || { echo "already running"; exit 75; }. flock(1), documented as a utility to "manage locks from shell scripts", ties the lock to an open file descriptor, so it is released automatically when the last process holding that descriptor exits or is killed — unlike a leftover PID file, it cannot go stale. Child processes inherit the descriptor: a daemon started from the locked script keeps the lock until it exits, unless started with 9>&-.
2. Use -n/--nonblocking to fail immediately if another instance already holds the lock (right for a scheduled job that should skip an overlapping run), or -w <seconds> to wait up to a timeout instead.
3. On FreeBSD, the equivalent is lockf -k -t 0 /var/run/my-admin-script.lock /usr/local/bin/my-admin-script.sh; lockf(1) is documented as a utility that "acquires an exclusive lock" on a file, creating it if needed, executes the given command while holding it, and releases the lock when the command completes. Without -k it deletes the lock file on exit; a lock conflict exits with 75 (EX_TEMPFAIL).
4. On Windows, use a named, system-wide mutex rather than a lock file: $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() }. If a previous holder died, the next WaitOne throws AbandonedMutexException but grants ownership, hence the catch. The .NET documentation distinguishes unnamed, process-local mutexes from "named system mutexes" visible across processes; the Global\ prefix makes the name span all user sessions.
5. Always release the lock/mutex in a finally/trap block so an exception during the script body still frees it; do not rely only on the normal exit path.
6. Log both outcomes distinctly: "skipped, another instance is running" is not the same event as "started" and should not be treated as a failure by whatever monitors the schedule.

Expected result

Starting the script a second time while the first is still running exits immediately (or waits, per the chosen mode) instead of running both copies against the same state; killing the first run's process releases the lock without manual cleanup.

Limits and test basis

flock's advisory locking only stops other processes that also go through flock/flock(2) — it does not stop a process that ignores the lock and edits the same files directly. Lock files on a network filesystem (NFS) may not enforce flock semantics consistently across hosts; keep the lock file on local storage for a single-host guarantee. A named mutex created by one account can be inaccessible (access denied) to a script running under another account; run every instance under the same account or grant access explicitly.