I have the following scenario:
In my work computer (A) I open a byobu (tmux) session.
Inside byobu, I open several terminals. Some of them are local to (A), but in others I ssh to a different computer (B).
I go home, and from my my home computer (C) I ssh to (A), run "byobu" and find all my sessions in (A) or (B).
This works perfectly, except for running X11 applications. I don't leave any X11 application running when I change computers, but just running "xclock" sometimes works and sometimes doesn't ("cannot connect to X server localhost:n.0").
I understand this depends on the DISPLAY
variable, and that it would be set up such that X11 would connect to the computer where I ran "byobu" last before creating the session inside byobu, and that could be (A) or (C). My problem is that often I don't know how to fix a session that's not working any more. Sometimes I can just open another session (another tab in byobu) and use the value of $DISPLAY
in other sessions, but that only works as long as the new session is open, and not always. In other cases I've been able to detach byobu (F6), re-attach it (run "byobu") and open a new ssh connection to (B), and then that one works, but not the already existing sessions.
I have read some documents like SSH, X11 Forwarding, and Terminal Multiplexers or How to get tmux X display to come back?, but it is unclear to me how they apply (if they do) to my situation. For instance, the .bashrc
code of the former, should it be in (A), (B), or (C)?
UPDATE/EDIT I have found the correct way to do this. Simply type this in any of the byobu shells
. byobu-reconnect-sockets
and the DISPLAY environment variable for your new ssh connection, as well as SSH_AUTH_SOCK and several others that may be useful and dependent on the primary login shell (that which you do byobu attach-session -t session_name
or for screen backend, byobu -D -R session_name
or however you do prefer to do it).
This is all supposed to happen simply by pressing CTRL-F5, but I suspect that like me, your computer is intercepting the CTRL-F5 (for me, I am using iTerm on a Mac) and either doing its own thing with it, or sending the wrong control character sequence so byobu doesn't receive it properly. It's a bit more typing, but sourcing the shell script as indicated above will do the same thing as CTRL-F5 is supposed to do, and will do it for ALL byobu open shells in the session. The rest of my original answer below you can probably now ignore, but I'll leave it there in case it is in someway useful to someone perhaps for some other purpose.
Also, you can edit the byobu-reconnect-sockets
script (it is just a shell script) and there are places to add additional environment variables you want updated, so really none of the below is necessary.
(original answer follows)
When you ssh in again and reattach your byobu sessions, it is likely that the ssh forwarded X11 display for your new ssh connection is not the same as the proxy display that initial ssh session created when you launched byobu. Suppose you ssh in for the first time and are going to start a new byobu session with many shells and perhaps many forwarded X11 windows, and this will all work fine, because that first ssh shell sets the DISPLAY environment variable to what it is listening on for X11 connections. This might be something like
[~/]$ printenv DISPLAY
localhost:11.0
all shells started by byobu (and tmux or screen on the backend) are going to inherit the setting of all the environment variables that were set when byobu was initially launched, ie, the X11 display that was forwarded for your user for your first ssh connection.
Then you detach your byobu session and go home, and ssh back in. But this time you get a different X11 display, because some other user has localhost:11.0. In your new ssh session that you started at home, the value of DISPLAY might be localhost:14.0 (say). For X11 forwarding through this ssh connection, X11 clients need to connect to the ssh X11 proxy at display localhost:14.0, not localhost:11.0. You will likely not have the authorization keys for localhost:11.0 at that point, someone else will, or worse, if they have disabled X authentication, the X11 windows you are trying to open are going to start showing up on their screen. All you need to do to make it work, is this -
printenv DISPLAY
and note the value shown (or copy it)export DISPLAY=localhost:14.0
(in this example it'd be that value, you'll use whatever value you get for #2 in your case)This annoys me constantly and I'd love to take the time to develop some hack of some kind to at least make this less tedious, and best of all would be to have it done along with ctrl-F5, which effectively does exactly all this, but for some other things you often want to reconnect with your new ssh session, especially SSH_AUTH_SOCK for ssh-agent.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With