[systemd-devel] Synchronization Between Services at Shutdown

Simon McVittie simon.mcvittie at collabora.co.uk
Thu Apr 2 07:04:54 PDT 2015


On 02/04/15 14:31, Lennart Poettering wrote:
> Hmm? I really don't see how the NFS vs wpa_supplicant issue has
> anything to do with dbus? NFS doesn't care about dbus at all...

It does inasmuch as it requires networking to be up, which *might*
require dbus (e.g. for NetworkManager).

> You need to order wpa_supplicant and NM Before=remote-fs-pre.target
> and pull it it via Wants=remote-fs-pre.target.

AIUI services with the default dependencies depend on remote-fs.target?
Distributions have historically supported NFS /usr and /var if
networking is done via ifupdown or something, and used (the LSB
equivalent of) remote-fs.target to represent that. NFS /usr or /var with
NetworkManager or similar already didn't work, because that needs D-Bus,
which needs /usr and /var.

systemd mandates an initramfs that mounts /usr (which has thankfully
made it into Debian 8, although for a while it didn't look as though
that was going to happen), but AIUI /var is still something that comes
up later?

It's very easy to get into circular dependencies here; there's the
remote filesystem issue, and also the fact that dbus-daemon wants to
resolve users/groups, hence might need NIS or LDAP to be up. I
personally consider some sort of automatically-synched local cache like
sssd to be a far better answer than NIS or LDAP, and NFS root better
than NFS /usr and/or /var, but I am not the only one whose opinion
matters when considering whether a feature regression in distributions
is acceptable.

I think the best solution might be a way for "dbus-daemon --system" to
not be required to be Before early targets like sysinit.target (to avoid
circular dependencies), but for it to survive until the final killing
spree anyway. Does systemd have a way to say that, or are
startup/shutdown dependencies always symmetric?

Please see https://bugs.freedesktop.org/show_bug.cgi?id=89847 for more
on this; one possible hack is to have dbus.service's ExecStop not
actually stop dbus-daemon, so that it stays around until the final
killing spree just before /usr and /var are unmounted.

I'm happy to modify dbus.service if that's (part or all of) the
solution, but before I can do that we need to come up with a solution
that doesn't cause new dependency cycles.

    S

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>



More information about the systemd-devel mailing list