| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
After a full docker restart, a replacement ingester can bind its unix socket while the old container is still draining; the old server's stop() then unlinked the path by name, deleting the new server's socket. The new server keeps listening on an unlinked inode and never recovers (BetterStackHQ Linear T-8292). - start() now binds to a unique temp path and atomically renames it over the target, so the path always points at a live socket and takeover of a still-bound path is a single step. - stop() records the bound socket file's (dev, ino) and only unlinks the path if it still matches, so an older generation never removes a newer generation's socket. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
| Back | FazBrowse Home | New Git URL |
Problem
After a complete docker shutdown/restart, unix sockets sometimes never recover.
Root cause is a cross-generation race in this gem's socket lifecycle:
On a normal rolling deploy (swarm stop-first) generations never overlap, so this never bit. After a full docker restart, swarm reconciliation can start the new task while the old container is still draining (5s DRAIN_TIME): the new server binds the socket, then the old server's stop() deletes the new server's socket file. The new server keeps listening on an unlinked inode forever — haproxy gets ENOENT on every connect and nothing ever recreates the file, until the replica is manually restarted.
The ticket's WARN Failed to remove socket file: NotFound log line is that manual restart: the victim discovering at shutdown that its socket file had been missing for its whole run. The harmful deletion itself was silent.
Fix
Error-message change: startup failures at the target path now raise Failed to install Unix socket file … (rename step) instead of Failed to remove existing Unix socket file ….
Tests
Full suite: 39 runs, 0 failures (1 skip = sudo-gated test).