From: smcv@debian.org   
      
   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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)