Sorry to bang on, but (1) previous comments don't seem editable, (2)
running the aforementioned script through http://www.shellcheck.net/
identifies some potential problems.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to
(But I've removed the cups and the 'up' bits.)
--
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
@Adam Felson
I'm trying out your script, combined with autofs (which doesn't work via
fstab).
--
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
I suffer from this too. It affects both systemd's automounts and autofs.
It's driving me nuts.
--
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
> ExecStop=/bin/sh -c "echo Stopping the system dbus-daemon is not
supported. Reboot the system instead.; exit 1"
This is nonsense and makes me wonder if I should switch back to Windows
instead.
Trolling intended.
--
You received this bug notification because you are a member of Ubuntu
Touch
Adam, can you confirm what link you have in pre-down? I created a link
in pre-down.d called pre-down pointing to nfs.sh in the higher
directory. When I included this script (on ubuntu 16.04), in systog I
get messages like:
root: ** NetworkManager dispatch script nfs, IF=none
after years of suffering with this bug, I found a solution that works for me.
I put a pre-down dispatch script for network manager to dismount nfs shares
when bringing the network down. This works even if a reboot is run from a
shell.
In /etc/NetworkManager/dispatcher.d/nfs.sh:
@stormhike do you run Upstart or systemd? I'm just wondering if this
works on systemd since you're modifying init scripts and I thought
systemd doesn't look at these.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dbus in
I have found a workaround on my 16.04.1 system (whether dbus problem that was
already fixed or not).
I removed the .sh from the umount files in rc0.d, rc6.d and init.d ...
su
cd /etc/init.d/
mv umountnfs.sh umountnfs
cd /etc/rc0.d
rm K05umountnfs
ln -s ../init.d/umountnfs K05umountnfs
cd
I got tired of having to gracelessly cut the power every time nfs
umounts hung. I slipped an unmount command into the desktop manager's
systemd init script. I run kubuntu, so the unmounts went into
/etc/init/sddm.conf.
--
You received this bug notification because you are a member of Ubuntu
To recent commentators, unless you are sure this is a problem caused
by dbus stopping too early then it is a different issue. Even if you
believe it is the same issue it is probably best to open new bug rather
than commenting on a closed one.
--
You received this bug notification because you
I experience a similar isses as Tommy. I mounted the NFS manually and
the computer will just not shutdown. Additionally I also failed mounting
the device via fstab but I used different options.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which
Apparently this is not a solved problem, as my fresh 16.04 install hangs on
shutdown with NFS drives mounted.
My fstab:
10.10.10.10:/media/storage1 /nasnfs
noauto,x-systemd.automount,soft,timeo=20,retrans=10 0 0
Un-mounting before shutdown makes it shutdown correctly.
Is
(In reply to Simon McVittie from comment #6)
Unfortunately, systemctl restart dbus (which was never supported either)
will now start a second dbus-daemon in parallel with the first
I think that's unacceptable.
(In reply to Lennart Poettering from comment #12)
If at all, use
** Changed in: dbus
Status: Confirmed = Won't Fix
--
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
(In reply to Martin Pitt from comment #13)
(In reply to Lennart Poettering from comment #12)
The best way is to fix the few services that really need dbus
unconditionally to be around to add After=dbus.service. And all is good.
If we go with that approach, then it would IMHO be cleaner to
Please do not apply that ExecStop= thing. You really shouldn't block
that. Think about people who boot their system with emergency on the
kernel cmdline, and thus get a PID 1 plus a shell and nothing else, they
should be able to start dbus and stop it as they wish...
If at all, use
(In reply to Lennart Poettering from comment #12)
The best way is to fix the few services that really need dbus
unconditionally to be around to add After=dbus.service. And all is good.
If we go with that approach, then it would IMHO be cleaner to change the
implied After=dbus.socket for
(In reply to Martin Pitt from comment #8)
I don't see anything explicit
which would declare cannot restart; I haven't tested this (travelling/no
real computer), but would something like
ConditionPathExists=!/run/dbus/system_bus_socket
prevent further starts/restarts?
Good idea, I'll
ExecStop=/bin/true was my first idea, but Martin rightfully pointed out, that
this doesn't influence KillMode, i.e. we need KillMode=none.
With that KillMode setting, I think we can actually drop ExecStop=/bin/true, so
what remains is
KillMode=none
systemd has a final killing spree, before it
(In reply to Simon McVittie from comment #6)
How's this? I made the stop command be echo instead of true so that it
leaves a hint in systemctl status if someone tries to stop it by hand.
Ah, good one.
Unfortunately, systemctl restart dbus (which was never supported either)
will now start a
(In reply to Michael Biebl from comment #1)
ExecStop=/bin/true was my first idea, but Martin rightfully pointed out,
that this doesn't influence KillMode, i.e. we need KillMode=none.
With that KillMode setting, I think we can actually drop ExecStop=/bin/true,
so what remains is
(In reply to Martin Pitt from comment #8)
ConditionPathExists=!/run/dbus/system_bus_socket
That can't be suitable, because dbus.socket creates that filesystem
object, so dbus-daemon would never start.
Removing --nopidfile and adding ConditionPathExists=!/run/dbus/pid in
addition to the
(In reply to Simon McVittie from comment #6)
Perhaps it would be better to make the stop command exit
nonzero?
Straw man:
ExecStop=/bin/sh -c echo Stopping the system dbus-daemon is not
supported. Reboot the system instead.; exit 1
... which does work, but logs Unit dbus.service entered
(In reply to Martin Pitt from comment #4)
I'm not sure if root on NFS was ever attempted/supported. You'd basically
need half an OS in your initramfs then? :-)
Yes it is/was, with or without an initramfs:
https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt
(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
(In reply to Simon McVittie from comment #7)
(In reply to Simon McVittie from comment #6)
Perhaps it would be better to make the stop command exit
nonzero?
Straw man:
ExecStop=/bin/sh -c echo Stopping the system dbus-daemon is not supported.
Reboot the system instead.; exit 1
...
Created attachment 114829
system bus: do not allow stopping the system dbus-daemon
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
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
Actually, this isn't the full story, as NetworkManager doesn't tear down
interfaces when it shuts down. So Colin, I'm afraid I need a shutdown
journal output from current vivid after all..
** Changed in: dbus (Ubuntu)
Status: Triaged = Incomplete
** Summary changed:
- D-Bus stops too
No problem. Attaching journal
** Attachment added: Journal showing wait on unmount when connected via wifi
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1438612/+attachment/4361872/+files/journal.txt
--
You received this bug notification because you are a member of Ubuntu
Touch
Public bug reported:
(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
Can you confirm that you have wpasupplicant 2.1-0ubuntu7 ? I. e. you
should see
$ systemctl cat wpa_supplicant.service |grep Before
Before=network.target
Your journal looks like it would stop wpa_supplicant before
network.target.
--
You received this bug notification because you are a member
Andy gets this issue as well (http://paste.ubuntu.com/10711795/)
** Changed in: dbus (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dbus in Ubuntu.
** Changed in: dbus (Ubuntu)
Status: Incomplete = New
--
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
Status in
dbus would be stopped by the final killing spree.
This usually looks like this
stop individual services in reverse order
Sending SIGTERM to remaining processes...
Sending SIGKILL to remaining processes...
Unmounting file systems.
All filesystems unmounted.
Deactivating swaps.
All swaps
Andy, Colin, can you please revert the workaround in
/lib/systemd/system/NetworkManager.service (remove After=dbus.service),
and instead append these lines in /lib/systemd/system/dbus.service, to
the [Service] section:
ExecStop=/bin/true
KillMode=none
This makes things work in my tests, and is a
Martin, your fix worked for me.
--
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 dbus
** Summary changed:
- remote file systems hang on shutdown
+ remote file systems hang on shutdown, D-BUS stops too early
--
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
I started a discussion with upstream in the linked fd.o bug, and
uploaded this in the meantime.
** Bug watch added: freedesktop.org Bugzilla #89847
https://bugs.freedesktop.org/show_bug.cgi?id=89847
** Also affects: dbus via
https://bugs.freedesktop.org/show_bug.cgi?id=89847
Importance:
Fixed here too.
--
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 dbus package in Ubuntu:
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
This bug was fixed in the package dbus - 1.8.12-1ubuntu5
---
dbus (1.8.12-1ubuntu5) vivid; urgency=medium
* Add debian/patches/dont-stop-dbus.patch: Don't stop D-Bus in the service
unit (see patch header and upstream bug for details). Fixes various causes
of shutdown hangs,
Yes, I have that version:
$ apt-cache policy wpasupplicant
wpasupplicant:
Installed: 2.1-0ubuntu7
Candidate: 2.1-0ubuntu7
Version table:
*** 2.1-0ubuntu7 0
500 http://gb.archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages
100 /var/lib/dpkg/status
$ systemctl cat
44 matches
Mail list logo
