Opened 11 years ago
Closed 10 years ago
#13107 closed defect (fixed)
VBoxClient should not be started for remote X11 sessions -> fixed in 4.3 and later versions released after 21 July 2014
Reported by: | Hrvoje | Owned by: | |
---|---|---|---|
Component: | guest additions | Version: | VirtualBox 4.3.12 |
Keywords: | Cc: | ||
Guest type: | X11 | Host type: | all |
Description
Hi.
While playing with remote display sessions, i stumbled upon VBoxClient. Problem is that when you run Xsession over SSH, VBoxClient is started from Xsession.d script, and it does work as expected.
For example, ssh to server machine using "ssh -X", and make sure that on client machine you have X server willing to accept X protocol. Starting desktop environment using Xession command, will cause desktop to be started, but also VBoxClient.
In this case VBoxClient sees display on remote machine, and does not have access to VBoxService. For some reason, this causes some wierd efects, one of them is that user is unable to select any text in terminal, and do copy/paste operations. I did test this with latest Ubuntu, using Lubuntu as desktop.
My suggestion would be to add check in /etc/X11/Xsession.d/98vboxadd-xclient script wheter are we run as local X11 session or remote one. Simple check would be to see if there is SSH_CONNECTION environment variable, and it it is, then do not run VBoxClient. Another way would be to check for XDG_SEAT variable, and if it is there, run VBoxClient.
There is also another error there. Scripts in /etc/X11/Xsession.d are not executed, but instead, they are sourced. As such, they _must not_ contain "exit" directives! And current script for VBox have one exit inside. This must be removed.
Regards.
H.
Change History (7)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
Hi.
Yes, i would say that this is quite similar to what i see. :-)
I think that it is safe to run without services, because in this case, they do not help.
Regards,
H.
comment:3 by , 10 years ago
Sorry for the lack of response - I was unavoidably away from work for quite a while. Does this look alright to you? The code path which formerly contained the "exit" directive is actually no longer needed, as these days we refuse to support pre-release X server versions.
$ svn di src/VBox/Additions/x11/Installer/98vboxadd-xclient Index: src/VBox/Additions/x11/Installer/98vboxadd-xclient =================================================================== --- src/VBox/Additions/x11/Installer/98vboxadd-xclient (revision 94874) +++ src/VBox/Additions/x11/Installer/98vboxadd-xclient (working copy) @@ -21,29 +21,11 @@ test -w $i || rm -f $i done -# Check whether the display we are running on running a known buggy version -# of X.Org which might crash when we resize. -no_display= -xorgbin=Xorg -found=`which Xorg | grep "no Xorg"` -if test ! -z "$found"; then - if test -f "/usr/X11/bin/Xorg"; then - xorgbin=/usr/X11/bin/Xorg - else - exit 1 - fi +# Do not use "exit" here as this script is "source"d, not executed. +if test -z "${SSH_CONNECTION}"; then + /usr/bin/VBoxClient --clipboard + /usr/bin/VBoxClient --checkhostversion + /usr/bin/VBoxClient --display + /usr/bin/VBoxClient --seamless + /usr/bin/VBoxClient --draganddrop fi -xout=`$xorgbin -version 2>&1` -if echo "$xout" | grep "1\.4\.99\.90[12345]" > /dev/null -then - no_display=1 -fi - -/usr/bin/VBoxClient --clipboard -/usr/bin/VBoxClient --checkhostversion -test -z "$no_display" && - /usr/bin/VBoxClient --display -test -z "$no_display" && - /usr/bin/VBoxClient --seamless -test -z "$no_display" && - /usr/bin/VBoxClient --draganddrop
comment:4 by , 10 years ago
By the way, I decided to use your idea of checking SSH_CONNECTION rather than something more generic on the grounds that this is the only case that we are currently aware of and I would prefer to avoid speculative generalisation until and unless we find more. I expanded the comment to say what we are actually doing...
comment:6 by , 10 years ago
Summary: | VBoxClient should not be started for remote X11 sessions → VBoxClient should not be started for remote X11 sessions -> fixed in 4.3 and later versions released after 21 July 2014 |
---|
Done.
I don't know if I am seeing the same as you here: I see something similar for the simple reason that I am ssh-ing into the virtual machine from the host system and this is causing a clipboard synchronisation loop: VBoxClient is running on the ssh X server which is proxying the host one and synchronising the clipboard to the host X server, so in effect trying to synchronise the host X server clipboard with itself.
The solution you propose would of course solve this, but I will have to think about it a bit.