Hello Simon, (In reply to Simon McVittie from comment #3) > (Also, is there any reason to prefer NFS /usr that doesn't apply equally to > preferring NFS rootfs?)
I'm not sure if root on NFS was ever attempted/supported. You'd basically need half an OS in your initramfs then? :-) > The fewer constraints we have to apply to startup, the better, to make it > more likely that dependency loops can be avoided in arbitrarily weird > situations (NFS /usr and/or /var, or networking infrastructure that needs > D-Bus - you can have one or the other but you cannot have both). So I would > be OK with giving dbus.service DefaultDependencies=no, but I would not > necessarily encourage requiring it to start before basic.target. Why not before basic.target? This would make it a basic system service which everyone could rely on. It's already kind of that through dbus.socket? It could lead to a more serialized boot of course, as non- dbus services would have to wait for dbus.service then. > If we give it DefaultDependencies=no and RequiresMountsFor=/usr /var /proc, > but do not order it either before or after basic.target, would that help? We don't need /proc, that's always available. "/usr /var" sounds like a good idea. I'd additionally have After=local-fs.target to ensure that you have a r/w root partition; or RequiresMountsFor=/ /usr /var. But any kind of dependency that we add here (and we have to) will lead to dbus.service being stopped at some time before that dependency/mount gets shut down, and then we are back to the situation that d-bus stops too early. In my experiments it again got stopped before any Type=dbus dependency, just because nothing else was directly depending on it. I have to use Before=basic.target so that it survives long enough during shutdown for all multi-user.target-like services to go down. > Then we'd get: > > startup: /usr and /var must be mounted before the system dbus-daemon starts > > shutdown: dbus-daemon must stop before /usr and /var are unmounted That's required indeed, but not sufficient. We also need to tell it to stop after consumers of dbus.service (which is really the whole point of this exercise). > Would not having the implicit Conflicts on shutdown.target mean that > dbus-daemon would survive the initial shutdown transaction and only be > killed when systemd got as far as unmounting the filesystems Unfortunately not, see above. This only works if you don't specify *any* dependency, but that's obviously not going to work for boot. > (In reply to Michael Biebl from comment #1) > > systemd has a final killing spree, before it unmounts the file systems and I > > don't think dbus needs to do something special on stop? > > It does not need to do anything special on stop. Is this killing spree > suffiently early that it happens before attempting to unmount /usr? It should better be, otherwise every random running process that the user and system left behind would block the unmounting. But I don't see how we can actually get to the point where dbus.service is never actually explicitly stopped; and we don't really need to, as long as stopping it happens sufficiently late. In my initial experiments this seems to work well: DefaultDependencies=no After=local-fs.target RequiresMountsFor=/usr /var Before=basic.target network.target Note that I didn't test this yet with a remote /var (or /usr). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dbus in Ubuntu. https://bugs.launchpad.net/bugs/1438612 Title: remote file systems hang on shutdown, D-BUS stops too early Status in D-Bus: Confirmed Status in dbus package in Ubuntu: Fix Released Bug description: (part of bug 1431774). During shutdown, D-Bus stops too early. In particular, it stops before NetworkManager and remote-fs.target, so that any network unmount will cause errors and hang the boot. This can be seen with $ journalctl -b -1 | egrep 'Stop.*(D-Bus|Network M|Remote F)' Mär 30 19:05:19 donald systemd[1]: Stopping D-Bus System Message Bus... Mär 30 19:05:19 donald systemd[1]: Stopped D-Bus System Message Bus. Mär 30 19:05:19 donald systemd[1]: Stopped target Remote File Systems. Mär 30 19:05:19 donald systemd[1]: Stopping Remote File Systems. Mär 30 19:05:19 donald systemd[1]: Stopped target Remote File Systems (Pre). Mär 30 19:05:19 donald systemd[1]: Stopping Remote File Systems (Pre). Mär 30 19:05:19 donald systemd[1]: Stopping Network Manager... Mär 30 19:05:42 donald systemd[1]: Stopped Network Manager. Mär 30 19:05:42 donald systemd[1]: Stopping D-Bus System Message Bus Socket. A quick workaround is to add After=dbus.service to /lib/systemd/system/NetworkManager.service's [Unit] section, but this should be fixed in a more general fashion. To manage notifications about this bug go to: https://bugs.launchpad.net/dbus/+bug/1438612/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
