Control: reassign -1 x2goserver 4.0.1.19
Control: reassign 1083 x2goserver 4.0.1.19
Control: merge -1 1083


On 25.06.2016 05:30 AM, Andy Wang wrote:
> From the error, I this appears to be resolved by using a custom session script
> in x2go and making sure to call: unset DBUS_SESSION_BUS_ADDRESS
> 
> For example:
> #!/bin/sh
> unset DBUS_SESSION_BUS_ADDRESS
> # redirect to /dev/null due to x2go bug 914
> /usr/bin/mate-session > /dev/null
> 
> Doing some digging, it looks like the dbus socket
> (/usr/lib/systemd/user/dbus.socket) on fedora 24 (dbus-1.11.2-1.fc24.x86_64)
> does this:
> ExecStartPost=-/usr/bin/systemctl --user set-environment
> DBUS_SESSION_BUS_ADDRESS=unix:path=%t/bus
> 
> And sets the DBUS_SESSION_BUS_ADDRESS for all logins for your user.
> 
> This same workaround appears to be what tigervnc used as their permanent solution:
> https://github.com/TigerVNC/tigervnc/commit/c071e493a093d7ee9a568729dd2e151f5cd3d749
> 
> So I think this is the proper solution.

Yes, we should probably also unset DBUS_SESSION_BUS_ADDRESS. If this env
variable is set, dbus-launch won't be used by the Xsession scripts (at least on
Debian, I didn't check Fedora or others) - otherwise dbus-launch will be used,
which is what we really want.


Merging the two bug reports.

This said, I guess I should do this in x2goruncommand, not in the Xsession
script directly.


However, this only fixes problems with full desktop sessions. I believe that we
should also unset DBUS_SESSION_BUS_ADDRESS and wrap all other commands in
dbus-launch. Does that make sense? Or does anyone have a justified veto?


And then, I have to take special care of pubapps sessions, which by default do
not spawn any command. Starting a new dbus session for each command spawned in a
pubapps session would be wrong. The situation is quite complicated in that case,
as there is no common command that is launched and stays available for the whole
session. (What happens essentially is that x2goagent is started and then kept
running, even if no other programs are currently running. Programs are then
executed by the client application, but there's no real concept of a session.)
I have to come up with something to make pubapps sessions behave in a sane way
related to DBUS.



Mihai