X2Go Bug report logs - #1046
x2go session causes dbus conflicts with logged in desktop on Fedora 24

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.x2go.org (full text, mbox, reply):

From: Andy Wang <dopey@moonteeth.com>

To: submit@bugs.x2go.org

Subject: x2go session causes dbus conflicts with logged in desktop on Fedora 24

Date: Fri, 24 Jun 2016 22:30:42 -0500

[Message part 1 (text/plain, inline)]

Package: x2goserver
Version: 4.0.1.19-8.fc24

When attempting to login with a client desktop session that uses dbus while
logged in as the same user on the console causes an error to appear in a
pop up window:
Could not acquire name on session bus

You can dismiss the error but the desktop never full starts and attempts to
logout triggers the logout on the console session.

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.

FYI, a bug was filed against Fedora as well:
https://bugzilla.redhat.com/show_bug.cgi?id=1350004

[Message part 2 (text/html, inline)]

Message #10 received at 1046@bugs.x2go.org (full text, mbox, reply):

From: Mihai Moldovan <ionic@ionic.de>

To: Andy Wang <dopey@moonteeth.com>, 1046@bugs.x2go.org, René Genz <liebundartig@freenet.de>

Subject: Re: x2go session causes dbus conflicts with logged in desktop on Fedora 24

Date: Fri, 10 Mar 2017 09:06:46 +0100

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, attachment)]

Message #19 received at 1046@bugs.x2go.org (full text, mbox, reply):

From: "Robert Nowotny" <rnowotny@rotek.at>

To: <1046@bugs.x2go.org>

Subject: Could not acquire name on session bus / Zesty / ubuntu-mate / x2go

Date: Mon, 26 Jun 2017 20:16:29 +0200

[Message part 1 (text/plain, inline)]

Had the same - unter x2go, pop up window:

 

Could not acquire name on session bus

 

System : zesty

Desktop: ubuntu-mate

 

edit the file:  

/etc/systemd/system/display-manager.service

 

right under section [Service]

 

add: 

 

unset SESSION_MANAGER

unset DBUS_SESSION_BUS_ADDRESS

 

And reboot the machine. Then it is working again.

 

Yours sincerely

Rnowotny / Vienna

 

 

 

[Message part 2 (text/html, inline)]

Message #24 received at 1046@bugs.x2go.org (full text, mbox, reply):

From: Robert Nowotny <rnowotny@rotek.at>

To: 1046@bugs.x2go.org

Subject: Could not acquire name on session bus / Zesty / ubuntu-mate / x2go

Date: Mon, 26 Jun 2017 22:12:22 +0200

[Message part 1 (text/plain, inline)]

Package:X2Go Server
Version : 4.0.1.20
System : Ubuntu 17.04 Zesty Zapatus, Kernel 4.4.0-81-generic
Desktop: MATE 1.18.0

After Launching the Client, it shows a black Window, showing "Could not acquire name on session bus"

First I suggested to edit the file/etc/systemd/system/display-manager.service - but that is wrong, then 
the desktop on the machine will note come up : ***** WRONG : 
/etc/systemd/system/display-manager.service

[Service]
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
.....

***** /WRONG - Desktop Session will not boot this way (remote desktop is 
working) ***** /etc/x2go/Xsession.d/75dbus_dbus-launch # $Id:$ # In 
order to activate the session bus at X session launch # simply place 
use-session-dbus into your /etc/X11/Xsession.options file # STARTDBUS= 
DBUSLAUNCH=/usr/bin/dbus-launch if has_option use-session-dbus; then # 
changed rn am 26.06.2017 - $DBUS_SESSION_BUS_ADDRESS is not zero length, 
but : "unix:path=/run/user/1000/bus" # if [ -z 
"$DBUS_SESSION_BUS_ADDRESS" ] && [ -x "$DBUSLAUNCH" ]; then # old code - 
STARTDBUS will ne not set if [ -x "$DBUSLAUNCH" ]; then # new code - 
STARTDBUS will be set to yes STARTDBUS=yes fi fi if [ -n "$STARTDBUS" ]; 
then # Note that anything that is D-Bus-activated between here and # 
95dbus_update-activation-env will not have the complete environment # 
set up by Xsession.d, unless the Xsession.d snippet that sets the # 
environment variable also calls dbus-update-activation-environment. # 
See <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815503> eval 
$($DBUSLAUNCH --exit-with-session --sh-syntax) fi


***** /etc/x2go/Xsession.d/75dbus_dbus-launch - now its working as 
expected on my machine ... yours sincerely Ing. Robert Nowotny Rotek GmbH

[Message part 2 (text/html, inline)]

Send a report that this bug log contains spam.