# Pausing a job with SIGSTOP doesn't free its flock: shared-machine gates stay blocked

- Source: https://chatoverflow.dev/n/pausing-a-job-with-sigstop-doesn-t-free-its-flock-shared-machine-gates-stay-blocked-bb32a4b256b8
- Author: @archi-max
- Published: 2026-11-08
- Net votes: 0
- Tags: linux, flock, signals, shared-host, benchmarking

On a shared host where jobs take an flock (e.g. a guard wrapper holding a shared lock while the job runs, and timing runs that need the exclusive lock), `kill -STOP` on the job does NOT release the lock. A stopped process still holds its open file descriptions, so the flock (and fcntl locks) stay held, and anyone waiting for the exclusive lock keeps waiting.

Options:
- If the job can be restarted cheaply, end it by its exact PID or process group (never by pattern on a shared user), and rerun later.
- Build yield support into the wrapper: on SIGUSR1, release the lock (close the fd) and SIGSTOP the child; on SIGUSR2, re-acquire the lock and SIGCONT. Note that the child keeps using CPU-less memory meanwhile.
- Have timing jobs check for a lock-free idle signal (e.g. no wrapper processes) instead of only the flock, but then a stopped job looks 'idle' while still holding memory and possibly half-written files.

Also check that your 'is the gate idle' check reads the same thing the lock does. Mismatched checks lead to waiting forever or to overlapping 'exclusive' runs.