[systemd-devel] Synchronization Between Services at Shutdown

[Dan Williams]

On Fri, 2015-04-03 at 14:01 +0200, Lennart Poettering wrote:
> On Thu, 02.04.15 15:04, Simon McVittie (simon.mcvittie at collabora.co.uk) 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).
> 
> In this case you should make sure that NM stays up until the NFS
> shares are unmounted, and if NM wants to have dbus around until its
> very end it should use After=dbus.service. However NFS mounts and dbus
> have little to do with each other.

NM does not need D-Bus to be up and around, and it doesn't care if D-Bus
goes away.

The only issue with D-Bus going away is for interfaces that require
external management daemons, like WiFi or Bluetooth, where if those
daemons exit the interface must be shut down because they have much more
hands-on control that is essentially required for the interface to
operate.  Those daemons either need to not exit when D-Bus isn't
available, or they need to get ported to kdbus or something.

Dan

> > > 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?
> 
> No. local-fs.target is part of the default dependencies, but
> remote-fs.target is not.
> 
> > 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.
> 
> Split-out /usr is not supported by systemd unless already mounted in
> the initrd.
> 
> Split-out /var is supported and does not have to be done in the
> initrd. It's incompatible of course with NM because NM needs dbus, and
> dbus needs /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?
> 
> Yes.
> 
> > 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. 
> 
> Well, no, this is not supported.
> 
> dbus is a late boot service, and it's difficult to change that. The
> major reason is bus activation: as long as dbus-daemon is running all
> its activatable names are activatable, and this easily results in
> deadlocks, since actually activating many of them would mean
> activating late boot services, which results in deadlocks all over the
> place. (simply because there is so much code that tries to contact
> some service if it can, but skips if it doesn't, that is run from udev
> rules or weird other early-boot stuff).
> 
> In kdbus this problem goes away since bus name are not always
> actviatable, but can be made activatable only during later boot. With
> kdbus we can schedule when names become activtable, which dbus-daemon
> simply doesn't support.
> 
> > 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.
> 
> Well, the way this is supposed to work with systemd is that NIS/LDAP
> becomes available with the nss-user-lookup.target target, and user
> logins wait for that (as well as remote-fs.target). NIS/LDAP only adds
> real (i.e. "human") users to the user database, and system users
> *must* exist all the time before that.
> 
> Both remote-fs.target and nss-user-lookup.target are *not* included in
> basic.target but are pulled in later.
> 
> > 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?
> 
> Yes they are always symmetric.
> 
> dbus-daemon cannot really be started before basic.target
> 
> > 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.
> 
> Urks! Don't do that.
> 
> > 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.
> 
> Honestly, services should not require dbus to be around when shutting
> down. And if they do anyway, they should simply specifiy the explicit
> After=dbus.service dependency, and all is good. Don't fuck up the dbus
> unit file, with lines like the above!
> 
> Lennart
>