[systemd-devel] Synchronization Between Services at Shutdown

[Lennart Poettering]

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.

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

-- 
Lennart Poettering, Red Hat