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 dbus
(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
Stat
@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 syste
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 syste
> 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 se
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:
/etc/NetworkMa
@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 Ubu
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 /etc/rc6.
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
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 a
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 i
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 th
** 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 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 RefuseManualSt
(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 clean
(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 Type
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 RefuseManualS
(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
https://anonscm.deb
(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 ne
(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
(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 patc
(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 f
(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 id
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 u
(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
(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
>
> KillMod
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 cons
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,
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
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:
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 pack
dbus would be stopped by the final killing spree.
This usually looks like this
Sending SIGTERM to remaining processes...
Sending SIGKILL to remaining processes...
Unmounting file systems.
All filesystems unmounted.
Deactivating swaps.
All swaps deactivated.
Detaching loop devices.
All loop devi
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
** 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
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 wpa_suppli
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.
https://bugs.launchpad.net/bugs/143
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 of
** 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 db
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 seed
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 ear
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 M|Remot
44 matches
Mail list logo