touch-packages team mailing list archive

[Bug Watch Updater <1438612@xxxxxxxxxxxxxxxxxx>]

Launchpad has imported 1 comments from the remote bug at
https://bugs.freedesktop.org/show_bug.cgi?id=89847.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2015-03-31T16:44:49+00:00 Martin Pitt wrote:

Downstream in Ubuntu we have gotten several reports of shutdown hangs
due to remote file systems trying to unmount when the wifi is already
down, and simlar issues. In journals [1][2][3] you see things like


systemd[1]: Stopping D-Bus System Message Bus...
avahi-daemon[694]: Disconnected from D-Bus, exiting.
whoopsie[685]: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.
NetworkManager[689]: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.
wpa_supplicant[1246]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:0f:66:57:07:7c reason=3 locally_generated=1
NetworkManager[689]: <info> (wlan0): roamed from BSSID 00:0F:66:57:07:7C (RedKite) to (none) ((none))
kernel: CIFS VFS: Server 192.168.1.93 has not responded in 120 seconds. Reconnecting...
systemd[1]: Unmounted <some remote file system path> → this is usually timing out as the network is not reachable any more
Stopped target Remote File Systems.
systemd[1]: Stopping Remote File Systems.
systemd[1]: Stopped target Remote File Systems (Pre).
systemd[1]: Stopping Remote File Systems (Pre).
systemd[1]: Stopping Network Manager...
systemd[1]: Stopped Network Manager.
systemd[1]: Stopping D-Bus System Message Bus Socket.

The main problem is that there is nothing that prevents D-Bus from
stopping very early, way earlier than all of the Type=dbus services.
There is an attempt to prevent that as systemd implies
"After=dbus.socket" for Type=dbus units, but that doesn't save us: you
can't re-start D-Bus after shutting it down and expect things to just
work, as it loses all of its state. And even if that would work, it's
rather pointless (and slow) to try and shut it down early just to have
it reactivate several times during shutdown. So in short, I think
dbus.socket doesn't really help us with anything except not having to
specify precise startup requirements; but we still need them for
shutdown.

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

Michael Biebl came up with a crazy, but neat idea for a workaround:

  ExecStop=/bin/true
  KillMode=none

i. e. don't actually stop dbus through the unit, and just let it get
killed at the bitter end. But on second thought it's actually quite
tempting: Stopping/restarting D-Bus during runtime has never been
supported, and always caused your desktop session and half of your
services to get killed, so in the distro we went out of our way to
prevent maintainer scripts etc. from doing that. So it's at least a nice
initial hack which isn't introducing dependency loops. But I figure we
should at least discuss a cleaner solution.

Of course this will all be obsolete with kdbus, as then dbus always
works. (Incidentally, not ever stopping it gets us rather close in that
regard :-) ).

[1] https://launchpadlibrarian.net/201680859/journal.txt
[2] http://paste.ubuntu.com/10711795/
[3] https://launchpadlibrarian.net/200211036/journal.txt

Reply at:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1438612/comments/10


** Changed in: dbus
       Status: Unknown => Confirmed

** Changed in: dbus
   Importance: Unknown => Medium

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

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