[systemd-devel] Synchronization Between Services at Shutdown

[Dan Williams]

On Thu, 2015-04-02 at 15:04 +0100, Simon McVittie wrote:
> 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).

NM requires wpa_supplicant running for WiFi because WiFi requires more
active management; the AP might go away, you might need to re-key, roam,
etc at any moment.  The supplicant can't really stop until you no longer
need the interface.  But in reality, (a) anyone mounting a rootfs over
WiFi is asking for trouble, and (b) why the F does NFS still not handle
network dropouts reliably?  But I digress.

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

NM hasn't needed dbus-daemon running for a long time in early boot, or
for any root-level operation.  So there's no requirement for /usr
or /var or anything else mounted, because root communication happens on
a private socket in /run.

wpa_supplicant does require dbus, since it has no private socket code.

Dan

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