Hi,

I found a few interesting things when trying to install the x2go server on a 
somewhat customized and mostly headless RHEL 7 VM in the cloud, specifically in 
this case on a RHEL 7.2.
These findings might help others, so I thought I'd post the details with some 
side notes.

Following the instructions on 
https://wiki.x2go.org/doku.php/doc:installation:x2goserver for RHEL 7 was not 
quite enough to install a working server on this specific RHEL 7 VM.
Due to the various documented issues with Gnome 3, I had switched the VM to 
"Server with GUI" with Xfce, but it still didn't help. On installing Xfce I 
even had to skip a broken dependency regarding sound support to make it 
install, but that is a side note only in case you also see something like that. 
I don't care about sound, so that single thing was easy to ignore for me.

In any case, when trying to connect with a Windows x2go client, not even the X 
desktop window on the client showed up initially.

Some investigation and log searching revealed that /usr/bin/x2goruncommand 
relies on dbus-run-session. This RHEL 7 machine only had dbus-launch because 
its dbus libs are older, and therefore it completely failed to even invoke the 
Xsession properly.
So I hacked x2goruncommand to do the following fallback:

----
               typeset dbus_wrapper="$(type -P "dbus-run-session")"
                typeset dbus_wrapper_args=""
                if [ -z "${dbus_wrapper}" ]; then
                        typeset dbus_wrapper="$(type -P "dbus-launch")"
                        typeset dbus_wrapper_args="--exit-with-session"
                fi
[...]
               XSESSION_EXEC="$cmd" STARTUP="/usr/bin/env 
LD_LIBRARY_PATH=${LD_LIBRARY_PATH} ${STARTUP}" ${dbus_wrapper} 
${dbus_wrapper_args} /etc/x2go/Xsession >> "$MESSAGE_FILE" 2>&1
----

This little hack was good enough to make the client show the server window, but 
I got a black window only. No remote desktop in sight still.
Using htop on the server, I saw that while the x2goagent was running, there was 
no xfce4 session of any kind or anything else that looked like a process 
related to any desktop session.

After a long set of weird and clueless debug steps I found a problem because I 
manually invoked "dbus-launch --exit-with-session /etc/x2go/Xsession".
It complained about elements in bash-completion.d not being valid identifiers, 
starting with "_itweb-settings()". Anything bad that can be fixed should be 
fixed while debugging along, so I started fixing those to see what might happen 
next.
Iteratively I went through the following files in /etc/bash_completion.d to 
remove the "-" from the function name identifiers only(!) that it was 
complaining about:

- rhn-migrate-classic-to-rhsm
- rhsm-debug
- rhsm-icon

After the manual invocation of the Xsession no longer complained about 
bash-completion, I tried the client and ... Ta Da! ... the session came up and 
seems to work well now.
I am sure there are other things that may need fixing and your mileage may 
vary, but all that is for another day.

The moral of the story: It's not always just older dbus libs or similar things. 
Even seemingly unrelated bash completion quirks can make the x2go Xsession 
script fail to start up ... and not show anything in any obvious log file.

BR,

Heinz

_______________________________________________
x2go-user mailing list
x2go-user@lists.x2go.org
https://lists.x2go.org/listinfo/x2go-user

Reply via email to