Comment 9 for bug 1021293

The offending process is /usr/lib/accountsservice/accounts-daemon.

I believe this can be worked around in log-output. However, there are multiple problems with accountsservice.postinst. Here's the fragment in question:

get_pid() {
    [ -n "$1" ] || return 0
    [ -S /var/run/dbus/system_bus_socket ] || return 0

    dbus-send --system --dest=org.freedesktop.DBus --print-reply \
              /org/freedesktop/DBus org.freedesktop.DBus.GetConnectionUnixProcessID \
              string:$1 2>/dev/null | awk '/uint32/ {print $2}'
}

if [ "$1" = "configure" ]; then
   # stop accounts-daemon
   pid=$(get_pid org.freedesktop.Accounts)
   kill $pid 2>/dev/null || true

   # restart daemon if it was running before
   [ -z "$pid" ] || /usr/lib/accountsservice/accounts-daemon & >/dev/null || true # will trigger through D-Bus activation
fi

I can see the following problems with this:

 1) There is no check that the process ID acquired via dbus-send is in the same filesystem root. If it is in a different root, accountsservice.postinst should leave well alone because the running executable is not the one that was just modified by unpacking the new version of accountsservice. The effect of this bug is that upgrading a chroot kills the running accounts-daemon in the host system.

 2) "& >/dev/null" is rather mangled shell syntax. Syntactically, & separates commands, and redirections are part of a command. The way this is written, the redirection is in fact part of a no-op command of its own, and is equivalent to opening and closing /dev/null without writing anything to it. Here's a demonstration of why this doesn't do what the author thought it did:

      $ echo hello & >x
      [1] 11962
      hello
      $
      [1]+ Done echo hello
      $ cat x
      $

    In any case, it should redirect stderr as well as stdout to /dev/null. Correct syntax would be:

      [ -z "$pid" ] || /usr/lib/accountsservice/accounts-daemon >/dev/null 2>&1 & || true # will trigger through D-Bus activation

 3) I'm less sure about this part, but given that it falls back to expecting accounts-daemon to be started by D-Bus activation, is there any reason to bother starting it from the postinst at all? It seems that perhaps you could simplify this by just deleting that code and relying entirely on D-Bus activation.