Each ssh domain session is by default a mirror clone, can't just close only one's own client session

[hgkamath]

Describe the bug

This needs some thinking. this issue is also a feature, just surprising and has some unintended consequences, such as closing one multiplexed session closes all multiplexed sessions.

Each fresh start-connected ssh domain session is by default a mirror/clone
What is typed or executed in one session is mirrored in a another.
Indeed, this is what multiplexing in it full glory means. I was only hoping to reap only disconnection-reconnection benefits.
This is not immediately obvious from a reading of
https://wezfurlong.org/wezterm/multiplexing.html?highlight=ssh#ssh-domains

Perhaps, this a desirable feature, and the problem is only that the way it is discovered is unexpected. It has its uses, such as tandem troubleshooting from multiple logins or from multiple machines/locations simultaneously/real-time. Maybe, when one wants a mirror-clone or reconnect to a disconnected session, one should explicitly connect to one by specifying a session-ID. There should be some indicator of how many mirror-clones are open and from where (ipaddress/client-machine). One should also be able to remote terminate other client-sessions, or terminate the session in immediate use without affecting others. Perhaps this is already doable from the wezterm-mux-server
I think permission/ownership/view/edit permissions are not required as this is not a security lapse as the user at every terminal already has ssh-login credentials.

Perhaps when starting a session, there is an argument/prompt for specified session-ID as to whether one want to mirror-connect to an existing session or start a new one.

Environment (please complete the following information):

• OS: [e.g. Linux X11, Linux Wayland, macOS, Windows]
  ssh session from vbox VM linux fedora-34 guest to windows-10 host
• Version: please run wezterm -V and include its output here

wezterm -V
wezterm 20210630-133255-ba42367f

• The active keyboard layout name (eg: ENG, DEU and so on)
  EN-US

To Reproduce

Steps to reproduce the behavior.

Please include as much information as possible that can help to reproduce and
understand the issue; some pointers and suggestions are included here in this
template. You are empowered to include more or less information than is asked
for here!

• Closing one wezterm-ssh-domain-session-window closes all others

  • Start a new wezterm ssh-window wezterm connect host-pc
  • Start another new wezterm ssh-window wezterm connect host-pc , or from another local wezterm window-session, from its +button start a new wezterm ssh domain session which will open in a new tab
  • Close any one of the wezterm ssh-domain windows
  • In addition to the one window being closed, all open wezterm-ssh-domain-session-windows to that ssh-domain will be closed, but local tabs if any, may survive. If a local tab is present, only the ssh-tabs disapear, leaving the window open with only the local-tabs
  • The 'really kill this window' confirmation dialog, however, is shown on only the window in which close is initiated. There is no indication that other client sessions will be closed.

• Each open wezterm-ssh-domain-session-windows are multiplexed mirror-clones of one-another

  • Enter a command and execute in any one window. The same command can be in real-time seen to be typed and executed in all other wezterm-ssh-domain-session-windows.
  • Start a new ssh tab in one window, identical tab is created in the other wezterm-ssh-domain-session-windows. newly created local tabs are not mirrored this way
  • I wonder what would happen if two different machines or logins initiated a wezterm-ssh-domain-session-window to the same use account on a machine, will all of them get mirror-clones. I expect that with this implementation, each machine/login will get a mirror of the same ssh domain session.

Strange effect wherein two mirror-clone ssh-domain-session-windows popup upon reconnection

• open a regular wezterm-local-window
• start a wezterm-ssh-domain-session-window
• from the regular wezterm-local-window, use the + button to start a ssh-domain-window
• confirm that both wezterm-ssh-domain-windows are now mirror-clones
• close one of the mirror-clones, both wezterm-ssh-domain-windows will close. In particular, the second wezterm process terminates.
• restart the wezterm-ssh-domain-session-window
• two mirror-clones appear, one from the restarted wezterm, one from the regular wezterm.
  It does not matter which mirror-clone is closed.
  However, sometimes a window will have gone into a "x-seconds since last response mode" in which case it does not get closed.

In general, it is hard to know which wezterm-window belongs-to/child-window-of which wezterm process. Inside the shell, there can only be a WEZTERM_PANE no. mirror-clone tabs all have the same WEZTERM_PANE nos. Hence, a tab/pane needs to be identified by clientmachine-process-window-session-tab-pane.

Strange undefined effect involving orphanned tabs/windows

• open a regular wezterm-local-window
• start a wezterm-ssh-domain-session-window
• from the regular wezterm-local-window, use the + button to start a ssh-domain-window
• confirm that both wezterm-ssh-domain-windows are now mirror-clones
• as before close one of the mirror-clones,
• as before restart the wezterm-ssh-domain-window, restarting both mirror-clones
• Start a new ssh-domain tab on the first regular-wezterm-local-window
  Things can go really undefined from there, sometimes a new wezterm-ssh-domain-session-window is opened, at other times, nothing happens. fedora-gnome-shell notification may show that an process start attempt was made.
  Sometimes, it can leave orphaned mirrored tabs, even weirder, the orphaned tab is mirrored to another tab in the same window

Maximizing a window/resizing a window can screw things up.

• when one of the mirror-clone wezterm-ssh-domain-window is maximised or resized. The other mirror-clones do not resize themselves. It is hard to know what to do in other mirror clones or how to bring the mirror clones back to same size easily. In them, it can be seen that text alignment is lost.

Configuration

As of today Jun 2021, issue #507 , requires that a wezterm-mux-server be running for ssh domain sessions to work

Be sure to include the relevant section(s) of your wezterm.lua configuration file.

  ssh_domains = {
    {
      name="host-pc",
      remote_address="10.20.30.2",
      username="gana",
    },
  },

Expected behavior

A clear and concise description of what you expected to happen.

• To make explicit whether one wants a mirror-session/reconnected-session or a fresh-session at session initiation time.
• If this is the default behavior, then this atypical behavior needs to be clear in the documentation. On the other hand if one wants behavior with minimal surprises, each new connection to ssh-domain-session must be to a fresh ssh-domain-session unless user explicitly requested to be connected to a pre-existing one,
• Presently, closing one multiplexed session closes all multiplexed sessions. When closing a multiplexed session, the prompt should ask whether to only close the users client session, or terminate all other client sessions also.
• resizing one mirror clone should resize all mirror-clones the same way.
• The ssh-sessions go into "seconds-since response" states quite often, especially when not foregrounded, occluded by other windows or not in focus. This can create orphaned windows/with orphaned tabs and extra ssh-domain windows with some tabs in one window and others elsewhere.

Screenshots

If applicable, add screenshots to help explain your problem. Screenshots are most
appropriate for rendering issues.

Session Recording

If the issue is with the way that escape sequences are processed it can be helpful
to capture the terminal output using the wt-record
script to run wezterm and record a transcript. This requires the script utility
to be installed on your system (this is part of macOS and available in the util-linux
package on linux systems).

In the example below a file named 20180225161026.tgz is produced. Please attach that
file to this issue, or if it contains private or sensitive issue that you don't want the
public to see on GitHub, please find some other way to get that file to a project
contributor (perhaps Dropbox or email?).

$ ./wt-record
Transcript recorded in 20180225161026.tgz

You can use wt-replay 20180225161026.tgz to replay that file.

wt-record can only record the terminal output; it cannot record the input events going
in to the terminal, so if you are having an issue with input, please be sure to describe
it below!

Additional context

Add any other context about the problem here.

[wez]

The mirroring behavior is intentional.

I think the most problematic portion of this issue is already tracked in #848

The multiplexer doesn't have a session concept today, but it will need to grow one in order to support #336 and I think that will give you the control that you want to have over wether you attach to an existing session or start a new one.

I think it is reasonable to expose some domain related info in PaneInformation so that uses can add indication to their tabs/status lines about the domain.

[hgkamath]

yes, #848 introduces the attach/detach semantics and expresses the idea that user should be aware and client should have some way to allow user to choose between attach/detach-session and new/kill-session,
and #336 will bring session management like tmux.

you can close this issue, if you think that issue raised are covered.

Just penning some thoughts

This is just the way it is in screen command and perhaps also tmux.
tmux and screen had only one ncurses-screen-buffer with swappable buffers and panes to manage.
Each buffer is the equivalent of a tab
wezterm could potentially have an additional degrees of freedom. multiple windows that could be connected with a session,

That leaves the questions

• Should window be an axis of session management?
• What to do with resizes.?

/==

• One should also be able to choose whether one is attach/detach-ing a session (whole set of tabs) or just a tab
• If one were to attach/detach a tab, and that tab has panes, then all panes in that tab need to be attach/detach-ed.
• If one were to attach/detach a window, and that window has tabs, which in turn may also have panes, then all tabs with panes associated with that window need to be attach/detach-ed.
• APPROACH-1: It seems to me, that as is currently implemented a session has only 1 window. But, if the implementation were to allow multiple windows per session, and if one were to attach/detach a session, then the set of windows in that session need to be attach/detach-ed. If session windows are managed by the the muxserver, then if a client/user moves a tab from one window to another, then the mux-server will have to ensure that that info is percolated to other clients/users and move that tab between corresponding session-managed windows. Window resizes will have less problems here and resizing info can be percolated and applied with less conflict. A session domain has to be in its own exclusive window, not shared with other session-domains, maybe optionally have some client freedom to include some independent local-shell tabs. An entire session-domain with all it windows will look the same in all clients/users. perhaps with some client freedom in tab order in window.
• APPROACH-2: (contradictory to approach-1) Perhaps, windows should NOT BE an axis of wezterm-mux-server session-management, BUT they SHOULD BE a client-side feature for tab organization. The client/user should be free to decide which tabs go into which window, put tabs in any order, be free to drag out tabs into new windows, or merge tabs into whatever window they choose as long as they are associated with the same wezterm process. The tabs associated with a session could get scattered around. As discussed later below, resizing can be more problematic here.
• Hence, by way of approach-2 to revise a previously mentioned point. when a session is detached, all tabs associated with the session, whichever windows they may be in, need to be detached. And, at the time of attaching to a session, perhaps a new window with all session tabs/panes is created, but the client/user is free to move them around into windows in any tab-order that client wishes.
• If window is a aspect of the client wezterm, a user, while starting of wezterm may specify whether they want a fresh wezterm process with new window, or a new window is thrown as part of an pre-existing specified wezterm process. The advantage of separate processes is crash insulation. The advantage of the added window, is that it may be easier to move tabs around.
• The multiplexer should be able to handle and user should be able to start brand-new sessions with its own set of tabs, and manage concurrent sessions..
• User should be able to connect to any session, window of session or tab of session by specifying session-ID.
• There needs to be some UI user-clue/hinting as to which domain/session-ID a tab is connected to and also to which local wezterm process the window is associated with ex WEZTERM_PID
• Perhaps, if a pane in a session pane is killed, it is killed in all clients. All clients will get new pane layout. If there is feature for client to detach a pane, and a pane is detached, perhaps, there will be a blank in the pane area in that client. If there is a feature to move pane to fresh tab in all clients, then it is to be moved to fresh tab in all clients. Perhaps, if there is feature to move pane to fresh tab in only one client, then client should recreate pane layout of original tab, blanking out other panes, but keeping moved pane in its place in the layout.
• If one client session resizes a window/tab/pane, and soon after also another client, then the two clients could end up fighting, each one messing up the other's view/alignments.
• Perhaps size information should be percolated to other clients, so that, if one client resizes it, others are notified and can act on the information, either manually or automatically resize their windows/panes to how the first client had resized it.
• If as in Approach-2, if window is a client-side-feature and not an axis of session management, Suppose in one client session, an attached-tab is on its own or with other tabs in a separate window, and in another client session, the corresponding attached-tab is part of a set of tabs in a window. The question is "what to do when window containing tabs of either side is resized?". Perhaps, the client should hint to user to pop out tabs into their own separate window if they cannot be jointly resized with other tabs in the window. But, if as in Approach-1, this issue won't arise if window is an axis of session-management. All tabs are stuck in their own window, and can only be resized together. It may be possible to real-time, via the mux-server move windows between session-managed windows. If a user wanted windows of different sizes, the user needs to start two different ssh-sessions with the mux-server, each session being free to be resized independently.

This feature, as you said, will need to grow incrementally.

[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.