mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-10 12:47:04 +00:00
kevinveenbirkenbachandClaude Opus 5
efe828b7a4
Every teardown left one node container behind, always the same one, and the warning blamed a kernel D-state. The cause was a budget: the client-unmount step gave all four containers one shared 120s allowance, the unmount chain costs up to three attempts per mount, and the third container in the list never got its turn. That container was then killed with its mount still attached. Killing was the second half of it. The node image sets STOPSIGNAL SIGRTMIN+3 so that `docker stop` triggers a clean systemd poweroff, but the teardown only ever ran `docker kill`, which skips it and leaves the nested engine and its task containers to die mid-flight. Those task containers hold binds of the NFS superblock inside their own mount namespaces, where an unmount in the node namespace cannot reach them, so the nested engine has to go down first. Under act the ansible controller is the act job container itself, so its own NFS mount is invisible to the host mountpoint check and survived every cleanup. Three more paths reached the same containers without any of this: the cross-cluster reaper removed them with no unmount at all and then reported the wedges it had just manufactured, the bootstrap pre-clean detached only inside the NFS server, and the escape hatch filtered its candidates down to `name=nfs-server` so it could never see the worker that actually survives. The removal verdict itself was wrong: a single inspect fired immediately after `rm -f` reports containers the daemon is still removing, and two of the three warnings in the observed run were false alarms. Verified by tearing a live five-node cluster down: all five containers removed, no remnant, no warning. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>