a "restart current SSH session" feature

[daishengdong]

a "restart current SSH session" feature

[daishengdong]

@youngtuotuo
Ah ha, thank you! this feature is quite impressive too, and demonstrates the powerful customization capabilities of WezTerm.

BTW, Tabby has the feature where every time it reopens, it automatically restores all tabs that were open at the time of the last close.

[daishengdong]

By the way, it's preferable for the tab title to remain unchanged before and after reconnecting via SSH.

This is because the tab title before the disconnection might have been "carefully" renamed, and it would be bothersome to rename it again with each reconnection.

[youngtuotuo]

@daishengdong I think you can try this feature
https://wezfurlong.org/wezterm/config/lua/SshDomain.html

After properly setup, you can simply wezterm connect server-name.
The only prerequisite is the remote machine also needs wezterm installed.

[daishengdong]

@youngtuotuo
hi, the ssh_domain happens to be the method I'm currently using to establish SSH connections (in fact, this has troubled me before, as I was unable to install WezTerm on the target machine, and previously, because I did not add "multiplexing = None", the SSH connection was always unsuccessful):

The problem I described is precisely the one faced when establishing a connection in a new tab using the ssh_domain method; if I were to directly use "ssh name@ip" in a local shell, the tab for the local shell should not automatically close if the SSH connection drops.

My current approach is to establish an ssh_domain connection in a new tab through showLauncher (bound to a shortcut key), and if the SSH connection is lost, the tab also closes. A more user-friendly way, as I described in my issue, is for the tab not to close automatically and to allow triggering a reconnection directly within this tab(better with a shortcut key).

[youngtuotuo]

@daishengdong

• The root cause is multiplexing = "None", this is the key feature of the tab restoration.
  From the link I gave:

That's also why you were unable to connect without multiplexing="None", since you didn't install wezterm on your remote machine.

• Simply use ssh command will not enable multiplexing feature, so it's normal that tab will close along with ssh disconnection.

• I think you need to figure out how to install wezterm in your remote machine, otherwise, no seesion will be stored.
  After endabling the multiplexing and installing wezterm on your remote machine, you can setup keyboard shortcut like this to detach/attach the ssh sessions

config.keys = {
  { key = "U", mods = "CTRL|SHIFT", action = act.AttachDomain("ubuntu") },
  {
    key = "D",
    mods = "CTRL|SHIFT",
    action = act.DetachDomain("CurrentPaneDomain"),
  }
}

• For Tabby/iTerm2 like restoration: when you close a tab, they just don't actually close them. They have a background process that handles all the connection, and, closing tab is simply closing UI, not closing ssh session, so that you can restore the ssh connections when you open the UI again.
  This is a brand new featrue for wezterm, the implementation may take times.

• If install wezterm on your remote machine is impossible, I recommend use tmux with the normal ssh connection.

[daishengdong]

@youngtuotuo
Yeah, I can get your point, if "multiplexing" then everything is ok.
But there is still a gap between us.

when you close a tab, they just don't actually close them. They have a background process that handles all the connection, and, closing tab is simply closing UI, not closing ssh session, so that you can restore the ssh connections when you open the UI again.

What I meant to say is not that "when the tab closes, the SSH session can still be maintained in the background by a standalone thread", but rather that "when the SSH session/network connection is lost, the tab still won't close." AND, If necessary, you can directly re-initiate the SSH/network connection on this "unclosed tab".

This doesn't require a separate thread, just a record of the relationship between the tab and the SSH domain, and providing an API that allows for the SSH connection to be directly re-initiated on the same tab.

I recommend use tmux with the normal ssh connection.

Yes, tmux can solve some problems, but not all, as the local machine could also shut down or restart, leading to the loss of the local tmux session.

The reason I'm making this feature request is that my work computer is a laptop, and my development machine is a remote server, so maintaining multiple ssh sessions is part of my daily development routine.

When I move my laptop between different networks, the SSH connection will drop.

If I have to go through the process of "1. using showLauncher to open SSH tabs, and 2. renaming the tabs to the name I want (since I have multiple remote servers)" every time, it becomes very annoying.

If the tab could be preserved after the network disconnects, it would be much more convenient to just use a shortcut key to re-initiate the SSH connection.

[youngtuotuo]

@daishengdong Got it. Sorry that I misunderstood your needs.

I think your requirement is related to these (but not 100% aligned)
https://wezfurlong.org/wezterm/config/lua/gui-events/gui-startup.html
https://wezfurlong.org/wezterm/config/lua/mux-window/spawn_tab.html?h=spawn_tab#cwd
#3646 (comment)

Like this

local wezterm = require "wezterm"
local mux = wezterm.mux

wezterm.on('gui-startup', function()
  local _, first_pane, window = mux.spawn_window {}
  local _, second_pane, _ = window:spawn_tab {domain = { DomainName = 'ubuntu' }}
  local _, third_pane, _ = window:spawn_tab {domain = { DomainName = 'rasberrypi'}}
  local _, fourth_pane, _ = window:spawn_tab { args = { 'ssh debian2' } }

  -- this is also a startup command
  second_pane:send_text "<insert busybox command>\n"
  third_pane:send_text "top\n"
  -- '\n' this will execute you shell command
end)

Then every time you open wezterm, those tabs will automacically open.

[wez]

Duplicate of #2080

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.