0

First off to anticipate confusion: this is indeed asking the opposite of your run of the mill tmux question.

How can one ensure that if the SSH tunnel dies, no tmux session is leaked at all. When running multiple shells over the same SSH session, terminating the session and the tmux instance cleanly in one terminal will still cause tmux instances in other terminals to leak. This can cause all kinds of trouble if e. g. one forgot to terminate a resource consuming process that was lingering hidden in some backgrounded pane. Not cool.

I’m using tmux almost exclusively as a terminal emulator and have little use if any for its “detach” feature. It’s not uncommon that I have multiple tmux instances in terminals accessing the same machine over a single SSH session. If I want to run a background process, I ask the shell to disown it or run it in systemd. Unfortunately, many systems I’m working with day to day haven’t upgraded to systemd yet and are unlikely to do that in the near future so KillUserProcesses is not an option.

Ideally I’d just invoke tmux with some command line switch that prevents it from running in the background so I can alias that to tmux.

What SSH tunnels?

One OpenSSH connection serving multiple sessions.

What tmux session?

Separate tmux instances, one per SSH session.

What leaks?

Leaks of tmux instances. As in: SSH into a machine. Start another shell session over the same connection. Start a tmux instance in each SSH session. You now have two tmux instances. Stop tmux in one session (<C-d>); then stop the SSH connection (again <C-d>): The other SSH session is closed but the tmux instance running inside it is leaked with all it child processes.

Please describe: (1) what setup you have now,

Stock OpenSSH, stock tmux, some shell. Mostly reverse SSH connections that I cannot reestablish to at will, but that shouldn’t matter.

and (2) what scenario you're trying to prevent.

Processes staying alive in the other tmux session.

Note that those are different boxes being SSH’d into, so the goal is to prevent even a single tmux instance from remaining alive after the connection dies. Also, since I use split panes and backgrounded windows heavily, I really wish for all the child processes to be collected.

  • How can one ensure that if the SSH tunnel dies, no tmux session is leaked at all. - What SSH tunnels? What tmux session? What leaks? Please describe: (1) what setup you have now, and (2) what scenario you're trying to prevent. Please skip rants about systemd, disown, and how you think they should work. Just describe the problem. – Satō Katsura May 7 '17 at 14:33
  • Untested and incomplete: create a script that executes tmux and gets either its PID or session name (whichever is easier). Then trap "kill $thepid" HUP or trap <however you delete a tmux session by name> HUP – Fox May 7 '17 at 17:17
2

When logging with new ssh session you can use something like tmux attach -d || tmux new to attach any existing tmux session or create a new session if no tmux sessions exist. While this won't prevent tmux session from running in background if you ssh connection drops, it will prevent these abandoned sessions from accumulating.

  • When the SSH connection fails this will leave all processes running inside that tmux session alive which is exactly the scenario I’m trying to avoid. Also I’m not attaching to the other session on purpose for multiple reasons. – user230251 May 11 '17 at 21:41
  • As I understand it is Ok for you to run all these processes while you are connected but not Ok while you are not. Why? What is the difference? – AlexD May 11 '17 at 21:52
  • As I understand it is Ok for you to run all these processes while you are connected but not Ok while you are not. -- Maintenance work on other people’s machines. If the connection goes down but a packet dump (real life example!) continues filling up disk space, you’re in trouble sooner than later. – user230251 May 11 '17 at 22:03
  • I don't see a difference in this example. Packet dump will fill disk faster if you are still connected due to traffic generated by your connection. – AlexD May 11 '17 at 22:09
  • Packet dump will fill disk faster if you are still connected due to traffic generated by your connection. Please read the question. The point is for tcpdump to terminate if the SSH connection fails. Besides, in the example scenario the SSH connection wasn’t even captured. – user230251 May 12 '17 at 19:53
1

I believe your problem can be avoided entirely by using Mosh.

Mosh supports intermittent connectivity, and only leaks mosh-server instances if you don't disconnect properly (such as forcefully closing the client while disconnected from the server).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.