touch-packages team mailing list archive

[Martin Pitt <martin.pitt@xxxxxxxxxx>]

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