busybox httpd forks a CGI child per HTTP request, so two near-simultaneous
deploy calls (an upstream proxy retrying a slow cold deploy, a browser
double-fire, an overlapping webhook) ran two `git reset/pull` in the same
repo at once and collided on .git/index.lock or a remote-tracking ref
("cannot lock ref ... is at X but expected Y"). Nothing in the chain
HTTP -> CGI -> wrapper -> deploy.sh serialized them.
Hold a non-blocking flock on fd 9 in the generated FORCE_COMMAND wrapper,
which is exec'd by BOTH the HTTP CGI and sshd ForceCommand. A second
concurrent request returns a friendly 200 and leaves the in-flight winner
alone, so an upstream proxy won't retry-storm and connections don't pile
up on a stuck build (busybox flock has no -w timeout). fd 9 stays open
across the exec, so the lock is held for the whole command and releases
when the process tree exits -- even on SIGKILL.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Fabian @ Blax Software
256a8c4571