[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