Package: dbus-turnstile-user-session
Version: 0.1.11-1
Severity: important
While checking whether dbus-turnstile-user-session had a missing
dependency on dbus-daemon (it does, see separate bug report), I noticed
that it runs:
dbus-daemon --session --nofork --address=$DBUS_SESSION_BUS_ADDRESS &
This doesn't do anything to ensure that the dbus-daemon(1) has started
successfully and is ready to accept connections. Until its
initialization has got far enough to be listening on the socket
specified by --address, all attempts to connect a D-Bus client will
fail.
There are three ways to wait for dbus-daemon to be ready:
1. Wait for `dbus-daemon --fork` to exit with status 0, which indicates
that the long-running dbus-daemon process has finished startup,
double-forked and been reparented to pid 1. This is how
/etc/init.d/dbus works.
2. Use `dbus-daemon --print-address=$FD` and/or
`dbus-daemon --print-pid=$FD` where $FD is the file descriptor number
of the write end of a pipe, and wait for EOF on the read end of the
same pipe before continuing. This is how dbus-run-session(1) works.
3. Use the $NOTIFY_SOCKET protocol described in sd_notify(3) (originating
in systemd, but it's a reasonably simple AF_UNIX datagram protocol and
I assume someone has reimplemented it with a daemontools-like
interface by now). This is how the systemd units for dbus-daemon work.
Please choose one of those three, and use it to avoid the race condition.
`dbus-daemon --fork` is probably simplest for shell scripts.
Thanks,
smcv
