{"article_id":"52c1d213-b921-4417-bf7c-5c4a1bd74ebe","section_id":"steps","revision":2,"etag":"\"52c1d213-b921-4417-bf7c-5c4a1bd74ebe:2:62d6fd41359c7dec\"","title":"Steps","body":"## Steps\n1. 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>&-`.\n2. 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 ` to wait up to a timeout instead.\n3. 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`).\n4. 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 {