98

Assume I have a tmux (1.7) window split as follows:

 ________________________
|           1            |
|                        |
|-----------+------------|
|     2     |      3     |
|___________|____________|

Now, the vertical sizes have been customized, so it's by no means one of the default layouts.

On occasion, when a program gets stuck or when you reboot a machine to which you connected via ssh, the pane "hangs". I.e. nothing other than kill-pane appears to work.

However, since there is no easy way to rebuild above split configuration once pane #1 has been kill-paned, I'd like to "restart" it.

0xC0000022L
  • 16,593

2 Answers2

159

Looking at the manual, the command respawn-pane struck me, but it turned out that this didn't work. Reading more closely, it turned out that respawn-pane -k was the answer, since it would kill the running command.

This way a pane can be "restarted" and spawned anew in place.

So <prefix>+: and then enter respawn-pane -k and press Enter

0xC0000022L
  • 16,593
  • 4
    Or use without -k if you created the pane in remain-on-exit mode and killed the command yourself. – peterph Aug 03 '15 at 20:26
4

Actually, there is a way to rebuild a layout - list-windows gives you a layout description for all windows in a session and select-layout can digest parse the string and set the layout appropriately (see select-layout in the man page tmux(1)).

As for your ssh problem - ssh servers should close connection once the system shuts down (although I have seen some Linux distributions which somehow mess up the proper behaviour by not shutting down the ssh daemon and running sessions properly) - if that is the case, see the ESCAPE CHARACTERS section (and other places referring to it) in ssh(1) - escape character followed by . (a dot) forcefully terminates the connection on the client side. Of course it doesn't help if you just spawned the pane with ssh running in it, but if you experience the problem more often, perhaps you'd rather want to run a shell in the pane and call ssh from therein.

peterph
  • 30,838
  • I upvoted your answer, because it adds value. But here's why the escape characters are not necessarily a good idea: using an ssh session in order to connect to a tmux session which has open ssh connections. Then you suddenly need to think about how to send the escape character beyond first ssh connection to reach the inner one(s). And btw, I usually run ssh from a shell. – 0xC0000022L Jul 31 '15 at 08:18
  • 2
    Pretty much the same thing as when you are running nested tmux sessions. Either you have different escape characters in the outer and inner session (be it ssh or tmux one) or you just send the escape character twice - which makes it go as a single one into the nested session (hard-wired behaviour for ssh, configurable in tmux). – peterph Aug 03 '15 at 20:25