[systemd-devel] Random session bus availability with systemd

tomw tomw at ubilix.com
Fri Aug 8 01:44:54 PDT 2014


migrating from sysV to systemd I ran into some issues with random
behavior of session bus availability. The setup is as follows:

systemd starts a service which starts an x-session like this:

Description=Master Process
After=systemd-user-sessions.service systemd-udedvd.service dbus.service

ExecStart=/usr/bin/sudo -b -u xyzuser -i /usr/bin/startx /usr/bin/master


Master then starts some other processes which all start after one after
another upon their appearance on the session bus, i.e. process1 is
started as soon as process0 appears on the session bus with its well
known name.
This approach used to work reliably under sysV. 

Moving to systemd it seems that there are some timing issues which
result in an random failure of the approach. The reason for that failure
is that sometimes process1 does not properly appear with it's name on
the session bus. As a result the subsequent processes do not start.

Loaded: loaded (/lib/systemd/system/master.service; enabled)
   Active: active (running) since Fri 2014-08-08 08:16:50 CEST; 17min ago
  Process: 519 ExecStart=/usr/bin/sudo -b -u xyzuser -i /usr/bin/startx /usr/bin/master (code=exited, status=0/SUCCESS)
 Main PID: 544 (sudo)
   CGroup: /system.slice/master.service
           ├─544 /usr/bin/sudo -b -u xyzuser -i /usr/bin/startx /usr/bin/master
           ├─555 /bin/sh /usr/bin/startx /usr/bin/master
           ├─860 xinit /usr/bin/master -- /etc/X11/xinit/xserverrc :0 -auth /tmp/serverauth.VP0SdUCg...
           ├─861 /usr/bin/X -nolisten tcp :0 -auth /tmp/serverauth.VP0SdUCgVO
           ├─867 python /usr/bin/master
           ├─871 /usr/bin/dbus-launch --autolaunch fbf381267b161fcf27363a6453d687d7 --binary-syntax --...
           ├─872 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
           ├─873 /usr/bin/python2.7 /usr/bin/process0
           └─882 /usr/bin/process1

As the approach used to work with sysV it seems I'm missing some point
with the session bus setup under systemd.
Any idea how to fix this or to get to the root cause is highly

tomw <tomw at ubilix.com>

More information about the systemd-devel mailing list