fix: lsof port backend counts only listeners (v1.0.1)#34
Merged
Conversation
…v1.0.1) With `lsof` as the port tool, ate_port_listening / ate_port_pids ran `lsof -ti tcp:PORT`, which also matches ESTABLISHED sockets — so any client CONNECTED to a dev-server port (a browser, a peer's inbound connection) was reported as the port's holder. Worst case: `ataegina down` mistook such a client for the server and refused to reap a process ataegina itself launched, orphaning it. Both branches now pass `-sTCP:LISTEN`, matching the `ss -l` backend — only true listeners count. Found dogfooding a real multi-worktree repo: `down` misattributed frontend ports to `chrome` and a `gnome-shell` extension (clients connected to those ports) and would not stop the backends it had started. Also bumps VERSION to 1.0.1, regenerates the checksum, and adds a [1.0.1] CHANGELOG entry. New hermetic regression tests/lsof_listen_filter.bats (4 tests): a fake lsof that mirrors real lsof's LISTEN-vs-client behavior + exit codes proves a client-only port reads as stopped/free (status + doctor), while a real listener is still detected. Mutation-verified: dropping -sTCP:LISTEN fails the client-only tests. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug (found dogfooding a real repo)
With
lsofas the port backend,ate_port_listening/ate_port_pidsranlsof -ti tcp:PORT, which matches any socket on the port — including ESTABLISHED sockets, i.e. any client connected to a dev-server port. Consequences on anlsofbox:status/doctorcould report a port "held" by a client (observed:chrome, and agnome-shellextension) rather than the server.ataegina downmistook a connected client for the port holder and refused to reap a backend ataegina itself launched — orphaning a real process (that was hitting a live DB).The
ssbackend was already correct (-l= LISTEN only); onlylsofwas wrong.The fix
Add
-sTCP:LISTENto bothlsofinvocations — listeners only, matchingss -l.Proven at the OS level: with a real listener + a real client in a separate process,
lsof -ti tcp:Preturns both pids;lsof -ti tcp:P -sTCP:LISTENreturns only the listener.Discipline
tests/lsof_listen_filter.bats— 4 hermetic tests via a fakelsofthat mirrors real lsof's LISTEN-vs-client output and exit codes: a client-only port readsstopped/free(status+doctor), a real listener is still detected (filter doesn't over-hide).lsof.-sTCP:LISTENfails exactly the two client-only tests.port_tools.bats/doctor.bats/status.batsunaffected; full suite 322/322 green locally.[1.0.1],VERSION=1.0.1, checksum regenerated.Patch release v1.0.1; the tag is cut after merge (triggers the automated release).
🤖 Generated with Claude Code