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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
