Random session bus availability with systemd
tjoen
tjoen at dds.nl
Fri Aug 8 09:53:30 PDT 2014
On 08-08-14 08:49, tomw wrote:
> ExecStart=/usr/bin/sudo -b -u xyzuser -i /usr/bin/startx /usr/bin/master
> [Install]
> WantedBy=multi-user.target
>
> 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.
>
> 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.
>
I understand from your story that process1 takes too long to start so
next processes failed to start. That is because everything in
multi-user.target
start at the same time resulting in delays in e.g. disk read.
Not most elegant but easiest is to put a sleep 5 after process1
More information about the dbus
mailing list