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