v1.8.2 — Fix run-lock surviving Ctrl+C

Bug fix: a Ctrl+C'd run no longer wedges future runs

Symptom

Pressing Ctrl+C during a run — typically while docker compose pull was in flight under --parallel — left the flock run-lock permanently held. Every subsequent run then bailed out immediately with:

Another hoist run holds the lock (/tmp/hoist.lock); exiting.

The only recovery was to find and kill the stray process or reboot.

Root cause

The run-lock is a flock held against the open file description, which the kernel releases only when the last copy of that file descriptor closes. Bash sets no close-on-exec flag on the {_LOCK_FD} redirection fd, so every docker/docker compose child and every &-spawned parallel worker inherited it. A Ctrl+C mid-pull could orphan a docker subprocess (the signal handler's pkill -P reaches only direct children, and races the worker's death), and that orphan kept the inherited fd — and therefore the lock — alive long after hoist itself had exited.

Fix

After acquiring the lock, hoist now hands the held fd to a single childless holder process and closes its own copy, so nothing it later forks or exec's can pin the lock:

• The holder is disowned, keeping it out of the job table so the parallel pool's wait / wait -n ignore it.
• An EXIT trap — also reached via the INT/TERM handler's exit — kills the holder, releasing the lock the instant hoist truly exits, regardless of any orphaned docker children left behind.

The result: serial and parallel runs release the lock cleanly on Ctrl+C, SIGTERM, or normal exit. The mkdir-fallback lock path (used when flock is absent) was already covered by its stale-PID detection and is unchanged.

No configuration or label changes. Drop-in upgrade — run hoist --update.