Live handoff refused any session with more than 64 panes. The pane count
was checked twice against MAX_FDS_PER_HANDOFF, and the transfer itself put
every pane's pty master into one SCM_RIGHTS control message, so the guard
was the only thing keeping the send inside the kernel's per-message limit.
A session past the limit could only be updated by closing panes or by a
normal restart, which ends every pane process.
Send the descriptors in batches of 64 instead and drop both guards. The
receiving side accumulates across recvmsg calls until the expected count
arrives, bounds every SCM_RIGHTS payload it reads by the control bytes the
kernel returned, rejects a batch that carries more descriptors than it
asked for, and closes the descriptors it already holds on any failure. A
session of 64 panes or fewer still produces one batch, so the bytes on the
wire are unchanged and HANDOFF_VERSION stays at 1.
refs #3393
Co-authored-by: kataokatsuki <kataokatsuki@users.noreply.github.com>
Co-authored-by: JJ Liebig <jonathan.liebig@gmail.com>
* fix: run the full applicable test suite on windows
* test: remove redundant test shell assignment
* test: make endpoint and metadata fixtures deterministic
* test: tolerate exited servers during windows probe cleanup
live_server_holds_one_pty_master_fd_per_pane counted only /proc/<pid>/fd links
resolving to exactly /dev/ptmx. On devpts setups such as WSL2 and many
containers, a PTY master fd resolves to /dev/pts/ptmx instead, so the test found
zero masters and failed with "had 0 ptmx master fds; expected 1" even though the
server held the pane's master fd. Match both ptmx node paths; pty slaves still
resolve to /dev/pts/<N> and stay uncounted, so the one-master-per-pane invariant
is unchanged.
Can Celik
Andrew Krasnoff