Session dbus lauched by /etc/X11/Xsession.d/75dbus_dbus-launch dies immediately

[Michał Sawicz]

We've been troubleshooting an issue with dbus on:

$ system-image-cli -i
current build number: 115
device name: frieza_arm64
channel: ubuntu-touch/staging/ubuntu
last update: 2017-01-05 18:30:16
version version: 115
version ubuntu: 20170105.1
version device: 20161014.0
version custom: 20170105.1

I've come to the conclusion as follows:

The session dbus daemon is launched by lightdm through Xsession.d/75dbus_dbus-launch (pstree):

systemd,1 fixrtc
  `-lightdm,2384
      `-lightdm,2439 --session-child 11 16
          `-dbus-launch,2692 --exit-with-session ubuntu-touch-session
              `-dbus-launch,2747 --exit-with-session ubuntu-touch-session
                  `-dbus-daemon,2748 /usr/bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session

Due to how the touch session is set up, dbus-launch subsequently kills the daemon because of the --exit-with-session option. Not sure exactly how/why this happens yet.

The dbus-launch PID is replaced with upstart:

phablet 2692 13.6 0.1 45948 3688 ? Ss 19:25 0:21 upstart --user

It was fine so far because the session upstart dbus job launched a session dbus regardless. With the change in https://launchpad.net/ubuntu/+source/dbus/1.10.6-1ubuntu3.2 however, it won't launch one if DBUS_SESSION_BUS_ADDRESS is set already. The environment is left with the address of the dead session dbus and so we're left with a bogus environment variable...

=== Workaround ===

It's possible to disable the Xsessions-dbus script by editing /etc/X11/Xsession.options and commenting out the following entry:

use-session-dbus

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: ubuntu-touch-session 0.108+16.04.20161206-0ubuntu1
Uname: Linux 3.10.93+ aarch64
ApportVersion: 2.20.1-0ubuntu2.4
Architecture: arm64
Date: Thu Jan 5 19:06:28 2017
PackageArchitecture: all
SourcePackage: ubuntu-touch-session
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.ubuntu-touch-session.d.android.conf:
 GRID_UNIT_PX=13
 QTWEBKIT_DPR=1.0
 NATIVE_ORIENTATION=landscape
 FORM_FACTOR=tablet
mtime.conffile..etc.ubuntu-touch-session.d.android.conf: 2016-10-14T08:44:51
upstart.bluez-mpris-proxy.log:
 Can't get on session busCan't get on session busCan't get on session busCan't get on session busCan't get on session busCan't get on session busCan't get on session busCan't get on session busCan't get on session busCan't get on session busCan't get on session busCan't get on session busCan't get on session busCan't get on session busCan't get on session busCan't get on session busCan't get on session busCan't get on session busCan't get on session busCan't get on session busCan't get on session busCan't get on session busorg.bluez appeared
 Bluetooth Adapter /org/bluez/hci0 found
 player core.ubuntu.media.Service at :1.1746 found
upstart.obexd.log:
 Failed to connect to socket /tmp/dbus-lf2wBKftE7: Connection refused
 Failed to connect to socket /tmp/dbus-ej3pH8DVYy: Connection refused
upstart.plymouth-log.override: manual
upstart.plymouth-shutdown.override: manual
upstart.plymouth.override: manual

[Robert Ancell (robert-ancell)]

I can't see any reason why LightDM could be affecting this - it only sets up the environment and then runs the session. Is this running under Mir? Because /usr/share/lightdm/lightdm.conf.d/52-ubuntu-touch.conf has:

[SeatDefaults]
type=unity
user-session=ubuntu-touch
session-wrapper=/usr/sbin/ubuntu-touch-lightdm-session
unity-compositor-command=/usr/share/ubuntu-touch-session/usc-wrapper

[LightDM]
minimum-vt=1

Which makes /usr/sbin/ubuntu-touch-lightdm-session:

if [ -n "$MIR_SOCKET" ]; then
    exec $@
else
    exec lightdm-session $@
fi

Which suggests under Mir none of the X session code would be run at all?

[Michał Sawicz (saviq)]

Well, if I comment out "use-session-dbus" in Xsession.options, the problem goes away, so I can't see how that doesn't get run...

Is MIR_SOCKET even set at that time?

[Robert Ancell (robert-ancell)]

MIR_SOCKET is set by LightDM, so it will be present when the Xsession is run.