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 > _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
