tmux session is detached when ever there is a broadcast message
Bug report
Thanks for filing an issue! Please answer the questions below so I can help you.
- iTerm2 version: Build 3.4.23
- OS version: 14.2.1 (23C71)
- Attach
~/Library/Preferences/com.googlecode.iterm2.plist
here (drag-drop from finder into this window) - Attach a [debug log], if possible.
- Attach a screen capture video if it would make the reproduction steps clearer.
PLEASE ATTACH YOUR PLIST FILE FOR BUG REPORTS! com.googlecode.iterm2.plist Seriously! I'll probably ask you for it if you don’t.
Detailed steps to reproduce the problem
- ssh -t gate1 '/usr/local/bin/tmux -u -CC new-session -A -t rbur004';
- In a non-iterm2 terminal (so it doesn't detach on you), send a broadcast message. eg using wall, though a system message will break the connection too
What happened
The tmux control session detaches, though the ssh session stays connected, (ssh session over which the tmux control session is running). A second wall will show up in the original iterm2 window. Reconnecting back to the host shows that the tmux session is still there
If the remote host is running Ubuntu 22.04, reconnecting to the tmux session does not display the original broadcast message in the tmux session, or the wall message sent after the iterm2 session detached, so it took me a while to realise that a message broadcast by nut was the cause of the disconnections. This was the case for the apt version tmux 3.2a and a compiled version 3.4
If the remote host is running FreeBSD 14.0, with the packaged tmux 3.3a, then reconnecting to the tmux session does show the wall messages. e.g
Broadcast Message from root@gate1
(/dev/pts/2) at 14:53 NZDT...
hello
Broadcast Message from root@gate1
(/dev/pts/2) at 14:57 NZDT...
Second wall
What should have happened
It should not detach from the tmux session
Screen shot.
- Top is the term session used to send the wall messages
- Middle is the now detached iterm2 to tmux window
- Bottom is the window used to start the tmux session from iterm2