touch-packages team mailing list archive

[Simon McVittie <1438612@xxxxxxxxxxxxxxxxxx>]

(In reply to Michael Biebl from comment #1)
> We might have a problem, if /usr is on NFS and (at least on Debian)
> dbus-daemon being installed in /usr/bin, which would keep the FS busy.

If dbus-daemon really badly needs to be moved to the rootfs, then it can
be... but in Debian, some libraries need to move first before that
becomes useful (libcap-ng0, libapparmor1).

If this is something we support upstream then I'd like to do it by
introducing a ${rootbindir} like systemd has, rather than moving
binaries around and patching systemd units etc. to compensate for it
like Ubuntu has traditionally done. But I would prefer not to have to
support it tbh.

(Also, is there any reason to prefer NFS /usr that doesn't apply equally
to preferring NFS rootfs?)

(In reply to Martin Pitt from comment #0)
> So what we really need is some way to say "Don't stop dbus.service before
> any D-Bus client" (i. e. *.service of Type=dbus). We could make dbus.service
> start before basic.target and stop after basic.target and add
> DefaultDependencies=no, so that it stops after most stuff; or change the
> implied After=dbus.socket in systemd to After=dbus.service. But that would
> also be prone to causing cyclic dependencies, if you e. g. have /var on NFS
> and need it to start dbus. (I didn't test that, it's just a gut feeling as
> remote file systems that you need to boot are notoriously susceptible to
> dependency loops.)

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.

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

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, or does it
schedule everything required for shutdown, including the unmounting, as
a single large transaction?

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

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