Comment 16 for bug 1438612

Hello Simon,

(In reply to Simon McVittie from comment #3)
> (Also, is there any reason to prefer NFS /usr that doesn't apply equally to
> preferring NFS rootfs?)

I'm not sure if root on NFS was ever attempted/supported. You'd basically need half an OS in your initramfs then? :-)

> 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.

Why not before basic.target? This would make it a basic system service which everyone could rely on. It's already kind of that through dbus.socket? It could lead to a more serialized boot of course, as non-dbus services would have to wait for dbus.service then.

> 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?

We don't need /proc, that's always available. "/usr /var" sounds like a good idea. I'd additionally have After=local-fs.target to ensure that you have a r/w root partition; or RequiresMountsFor=/ /usr /var.

But any kind of dependency that we add here (and we have to) will lead to dbus.service being stopped at some time before that dependency/mount gets shut down, and then we are back to the situation that d-bus stops too early. In my experiments it again got stopped before any Type=dbus dependency, just because nothing else was directly depending on it. I have to use Before=basic.target so that it survives long enough during shutdown for all multi-user.target-like services to go down.

> 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

That's required indeed, but not sufficient. We also need to tell it to stop after consumers of dbus.service (which is really the whole point of this exercise).

> 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

Unfortunately not, see above. This only works if you don't specify *any* dependency, but that's obviously not going to work for boot.

> (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?

It should better be, otherwise every random running process that the user and system left behind would block the unmounting. But I don't see how we can actually get to the point where dbus.service is never actually explicitly stopped; and we don't really need to, as long as stopping it happens sufficiently late.

In my initial experiments this seems to work well:

DefaultDependencies=no
After=local-fs.target
RequiresMountsFor=/usr /var
Before=basic.target network.target

Note that I didn't test this yet with a remote /var (or /usr).