Why does "lxsession&" via "ssh -X" make Ubuntu look different even after disconnecting?
Solution 1:
The Fix
Rebooting is sufficient to fix this, but not necessary. You can fix your desktop by logging out and back in. You would do this on the affected system, that is, the system whose desktop was messed up, the Ubuntu system that was used as the SSH client, not the Rapsberry Pi that was the SSH server. Note that just locking and unlocking the screen will not work--but logging out is enough.
If you're using Unity, it's likely running compiz --replace
on the affected machine would also work and avoid the need to log out, but I recommend logging out and back in.
Rebooting fixed the problem because it involved logging out and back in. It's okay, but not necessary.
What Happened
When you use ssh -X
and run a graphical program, the program:
- runs on the SSH server (here, the Raspberry Pi)
- displays on the SSH client (here, your Ubuntu system)
LXSession is LXDE's session manager. Running lxsession
on the SSH server from within the ssh -X
session starts a graphical LXDE session on the server using the client's display. This produces the two major changes you noticed:
lxsession
runs lxpanel
. LXDE uses LXPanel as its panel. It somewhat resembles the Windows taskbar in that it has a single panel defaulting to the lower edge of the screen that, unless customized, has (a) a single nested menu openable from the left edge of the panel from which applications are placed in groups and (b) a window list inside the panel itself that facilitates switching between applications.
lxsession
runs openbox
. LXDE uses Openbox as its window manager (see also this article and this page). Window managers control how windows are displayed; they are what allow you to switch, move, and resize windows; and they provide borders and styling. Your Unity interface uses the Compiz window manager. Because it was connected to the display on the SSH client, the openbox
instance running on the SSH sever attempted to manage the windows on the SSH client.
When you shut down and disconnected from the SSH server, all programs running on the SSH server that were using the SSH client's display stopped. The panel disappeared, as you observed. Openbox also stopped attempting to manage windows on the SSH client, but it had already displaced Compiz.
Other Possible Fixes
Those were the two major changes, but probably not the only ones. If you really wanted to know everything lsession
ran, you could consult both its documentation and read the configuration files on the Raspberry Pi that it uses, or you could try replicating the problem and running pstree
on the SSH server to see everything lxsession
started. But this is unnecessary. Logging out and back in is sufficient to set everything right again. Rebooting, as you did, is also sufficient.
Because the major problem was that Compiz was no longer working properly, running compiz --replace
on your Ubuntu system (the SSH client) would have fixed that. But logging out and back in is easy, simple, and doesn't require you to spend more time analyzing the problem.
Why You Didn't Find lxsession
on the SSH Client
After you closed the connection to the Raspberry PI (the SSH server), you tried the commands man lxsession
and lxsession
on your Ubuntu system that was the SSH client. You didn't have that manpage or that executable, however, because lxsession
wasn't installed--or running--on the SSH client. It was running on the SSH server and some of the programs it ran affected the SSH client.
If this were a Lubuntu system or you had otherwise installed LXDE--or lxsession
specifically--then you would have been able to view the manual page and run the program. This would not necessarily have been the same version of lxsession
as you have on the Raspberry Pi. You can try SSHing to the Raspberry Pi and running man lxsession
there. (Unless you are trying to reproduce the problem, I recommend against running lxsession
on the Raspberry Pi.)
What You Meant To Do
You could run X11 on Ubuntu without a session manager or even a window manager, and you could run ssh -X
and then lxsession
on the Raspberry Pi. With nothing like a existing X session already running, your desktop would not be disrupted. But I doubt this is what you want. You probably want one of three things:
-
To run individual graphical programs that are installed on the SSH server through
ssh -X
. In that case, just run those programs, e.g.,xclock
,firefox
,libreoffice
. SSH will forward them to the GUI on the SSH client. (If you want to be able to disconnect and reconnect without quitting the program, then one of the next two options may interest you, but see this answer and that one.) -
To run a persistent graphical desktop on the SSH server that you can disconnect from and connect to, without ending and restarting the desktop session. In that case, you won't want programs like
lxsession
to be limited to one SSH session or to directly use and rely on the SSH client's display. In this situation, one solution is to keep a graphical desktop running on the SSH server and connect to it from the client. This can be done, for example, with VNC or xrdp. (Remmina is a popular client.) Readers may need to ask new questions based on their specific situations, but see How do I set up xrdp session that reuses an existing session? - To make the SSH server fully manage a desktop on the SSH client. If you really want this, and you're already using a GUI on the client that you don't want to be disrupted--which is what happened to you--then you can run a second X server at the same time on the SSH client. Of these three options, I think this is the one you are least likely to want--though it is the most similar to what you did--and specific details of how to do it are beyond the scope of this answer. But see this question and that one.
Solution 2:
It was because you did lxsession&
not just lxsession
.
When you put &
at the end of a command, it will run in the background, so when you closed the session, the process was still active.
This is why rebooting fixed it as all the processes got shut down. including the background ones you created like lxsession&
.
Maybe next time try running it without the &
.