Comment 15 for bug 1438612

(In reply to Michael Biebl from comment #1)
> We might have a problem, if /usr is on NFS and (at least on Debian)
> dbus-daemon being installed in /usr/bin, which would keep the FS busy.

If dbus-daemon really badly needs to be moved to the rootfs, then it can be... but in Debian, some libraries need to move first before that becomes useful (libcap-ng0, libapparmor1).

If this is something we support upstream then I'd like to do it by introducing a ${rootbindir} like systemd has, rather than moving binaries around and patching systemd units etc. to compensate for it like Ubuntu has traditionally done. But I would prefer not to have to support it tbh.

(Also, is there any reason to prefer NFS /usr that doesn't apply equally to preferring NFS rootfs?)

(In reply to Martin Pitt from comment #0)
> So what we really need is some way to say "Don't stop dbus.service before
> any D-Bus client" (i. e. *.service of Type=dbus). We could make dbus.service
> start before basic.target and stop after basic.target and add
> DefaultDependencies=no, so that it stops after most stuff; or change the
> implied After=dbus.socket in systemd to After=dbus.service. But that would
> also be prone to causing cyclic dependencies, if you e. g. have /var on NFS
> and need it to start dbus. (I didn't test that, it's just a gut feeling as
> remote file systems that you need to boot are notoriously susceptible to
> dependency loops.)

The fewer constraints we have to apply to startup, the better, to make it more likely that dependency loops can be avoided in arbitrarily weird situations (NFS /usr and/or /var, or networking infrastructure that needs D-Bus - you can have one or the other but you cannot have both). So I would be OK with giving dbus.service DefaultDependencies=no, but I would not necessarily encourage requiring it to start before basic.target.

If we give it DefaultDependencies=no and RequiresMountsFor=/usr /var /proc, but do not order it either before or after basic.target, would that help? Then we'd get:

startup: /usr and /var must be mounted before the system dbus-daemon starts

shutdown: dbus-daemon must stop before /usr and /var are unmounted

Would not having the implicit Conflicts on shutdown.target mean that dbus-daemon would survive the initial shutdown transaction and only be killed when systemd got as far as unmounting the filesystems, or does it schedule everything required for shutdown, including the unmounting, as a single large transaction?

(In reply to Michael Biebl from comment #1)
> systemd has a final killing spree, before it unmounts the file systems and I
> don't think dbus needs to do something special on stop?

It does not need to do anything special on stop. Is this killing spree suffiently early that it happens before attempting to unmount /usr?