no connections made, cuz target machine refuse it #605

Activity

1. psmux

   added 2 commits that reference this issue on Aug 27, 2026

   fix(#605): a stale .port made attach print a raw winsock error

   ...

   d18d656

   fix(#605): a bare attach that finds nothing says no sessions, like tmux

   ...

   29a0e7b
2. psmux commented on Aug 27, 2026

   

   psmux

   on Aug 27, 2026

   Owner

   More actions

   Thanks for the screenshot, it was enough to pin this down. No connection could be made because the target machine actively refused it (os error 10061) is winsock's way of saying the port psmux had on record for that session had nothing listening on it any more: a server that died with the machine (a reboot of the VM, a crash, a killed console) but left its registration behind. psmux should have told you that in its own words, and quickly. Instead it stalled and printed the raw OS error. Both parts were bugs, and I could reproduce them here.

   What was happening

   1. The attach gate probes the registered port before committing. Its rule was "a refused connect means gone, any other failure means alive". On Windows a connect to an unbound loopback port is not refused promptly: the SYN is dropped and retransmitted, and the refusal takes about 2 seconds to surface (measured here across six ports: 2043, 2027, 2034, 2062, 2035 and 2049 ms). The gate only waited 500 ms, saw a plain timeout, and voted ALIVE for a server that did not exist.
   2. Having passed the gate, the client connected for real, and the resulting error was printed verbatim. The client's connect budget sat right on that retransmit boundary, which is where your took 4s came from.

   Fix

   Commit d18d656, with a follow up in 29a0e7b:

   • the gate is strict: any connect failure means no server, and the dead registration is reaped once the pid record agrees the process is gone (a live but busy server keeps its files)
   • a connect failure can no longer reach the terminal as an OS error: attach -t NAME answers can't find session: NAME, exit 1, and a bare attach answers no sessions, exit 1, which is the wording tmux 3.4 uses in the same situation
   • the first attach has its own 750 ms connect budget so a dead port cannot stall it through the retransmit

   Measured: a stale registration now answers in 184 to 649 ms with no OS vocabulary, against 2241 to 2986 ms and the raw error before. ls, has-session and new-session -A over a stale entry were checked too. The regression test scored 18 passed / 3 failed on 3.3.8 and 25 / 0 after.

   This is on master and will be in the next release. Until then, the workaround on your VM is to delete the stale entry by hand: remove <session>.port, .key, .sid and .pid from %USERPROFILE%\.psmux for the session that no longer exists, then psmux will start a fresh one.

   If you still see it after updating, please paste psmux ls and the contents of %USERPROFILE%\.psmux and I will dig further.
3. psmux

   added a commit that references this issue on Aug 29, 2026

   docs: audit against #582 to #616 and add SEO oriented tutorials, arch…

   ...

   a041e03