remote file systems hang on shutdown, D-BUS stops too early

[Martin Pitt]

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

[Martin Pitt (pitti)]

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

[Colin Law (colin-law)]

No problem. Attaching journal

[Martin Pitt (pitti)]

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.

[Martin Pitt (pitti)]

Andy gets this issue as well (http://paste.ubuntu.com/10711795/)

[Colin Law (colin-law)]

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_supplicant.service |grep Before
Before=network.target

[Martin Pitt (pitti)]

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 better fix IMHO. But I'd like to confirm that this works for you too. Thanks!

Background:

I discussed that with with Michael Biebl. D-Bus is really hairy as you get into circular dependencies very easily (with e. g. /var or /usr on NFS), so making it start earlier could miss out some important remote mounts. What we *really* want is to say "stop D-Bus after all D-Bus clients", thus synthesize After=dbus.service to all Type=dbus services. At the moment this only implies After=dbus.socket, but restarting dbus after you already shut it down isn't working as dbus cannot save/restore its state. At this state of the release cycle I don't have the guts to completely rearchitect this.

Also, stopping D-Bus in a running system isn't something which we ever supported; to the contrary, we patched several packages to avoid restarting/stopping D-Bus in postinsts, as stopping d-bus in a running system is shooting yourself into the foot (independent of which init system you use). Thus leaving D-Bus running until the bitter end should be fine, it doesn't have any file system things to do on shutdown. This also approximates the brave new kdbus world where d-bus is basically "always available".

[Michael Biebl (mbiebl)]

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 deactivated.
Detaching loop devices.
All loop devices detached.
Detaching DM devices.
All DM devices detached.
system-shutd[ 51.216341] reboot: Power down
own succeeded.
Powering off.

I don't think, there is anything special that dbus needs to do on stop.

[Michael Boratko (boratko)]

Martin, your fix worked for me.

[Colin Law (colin-law)]

Fixed here too.

[Martin Pitt (pitti)]

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

[Martin Pitt (pitti)]

I started a discussion with upstream in the linked fd.o bug, and uploaded this in the meantime.

[Launchpad Janitor (janitor)]

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, particularly with remote file systems. (LP: #1438612)
 -- Martin Pitt <email address hidden> Tue, 31 Mar 2015 18:46:06 +0200

[Michael Biebl (mbiebl)]

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 unmounts the file systems and I don't think dbus needs to do something special on stop?

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.

[Martin Pitt (pitti)]

(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
>
> KillMode=none

This doesn't actually work in my tests, the ExecStop= is needed (tested with systemd 219).

I was quite surprised that this fixed a lot more than just the hangs on unmounting network file systems. I also got reports that other vague shutdown hangs now disappeared (https://launchpad.net/bugs/1427672) and that shutdown hangs with libvirt's virbr0-nic interfaces are now gone as well.

[Simon McVittie (smcv)]

(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 need to move first before that becomes useful (libcap-ng0, libapparmor1).

If this is something we support upstream then I'd like to do it by introducing a ${rootbindir} like systemd has, rather than moving binaries around and patching systemd units etc. to compensate for it like Ubuntu has traditionally done. But I would prefer not to have to support it tbh.

(Also, is there any reason to prefer NFS /usr that doesn't apply equally to preferring NFS rootfs?)

(In reply to Martin Pitt from comment #0)
> 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.)

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.

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

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, or does it schedule everything required for shutdown, including the unmounting, as a single large transaction?

(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?

[Martin Pitt (pitti)]

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

[Simon McVittie (smcv)]

(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.debian.org/cgit/kernel/initramfs-tools.git/tree/scripts/nfs

> > The fewer constraints we have to apply to startup, the better [...]
> > 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 dbus.service *on a particular system configuration* is After something that is After basic.target, and basic.target is After dbus.service, then we have a cyclic dependency on that system configuration. (This is regardless of whether it works without cyclic dependencies for the relevant distribution's dbus maintainers, who presumably know enough to avoid bizarre boot orderings.)

Notable examples of things that dbus might need:

* NIS and other sources of users
* networking and other non-trivial infrastructure to get /usr

Debian and Ubuntu have traditionally run dbus as a rc2.d service, so there is nothing to stop it having such dependencies.

[Simon McVittie (smcv)]

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

Putting dbus.service Before basic.target was considered and rejected,
because it's a recipe for cyclic dependencies: as soon as
dbus.service wants to be After anything that is After basic.target
(e.g. NIS and other user databases, or remote filesystems) you
get a cycle. dbus-daemon does not need to start early, it only
needs to stop late.

systemd has a final killing spree before it unmounts the
file systems, which should be sufficient to avoid dbus-daemon
preventing a separate /usr from being unmounted; this does not
consider KillMode. dbus-daemon doesn't need to do anything special
during shutdown, so it's OK that it survives until then.

Based on a suggestion from Michael Biebl and Martin Pitt.

---

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.

Unfortunately, "systemctl restart dbus" (which was never supported either) will now start a second dbus-daemon in parallel with the first, and in my testing, the second one will get all new connections. Any ideas for how to avoid that? Perhaps it would be better to make the stop command exit nonzero? ... but then we'd log scary messages during a normal shutdown, which is no better really.

[Simon McVittie (smcv)]

(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 failed state" during shutdown. It seems better to avoid "crying wolf" if possible, because it can hide real issues.

[Martin Pitt (pitti)]

(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 second dbus-daemon in parallel with the first, and in my
> testing, the second one will get all new connections. Any ideas for how to
> avoid that? Perhaps it would be better to make the stop command exit
> nonzero? ... but then we'd log scary messages during a normal shutdown,
> which is no better really.

Right, I don't like making it fail on stop. 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? I'm not sure if conditions are evaluated on start only, or on restart too -- my gut feeling is the former, i. e. that won't work.

Thanks!

BTW, this is being discussed on the upstream ML too:

http://lists.freedesktop.org/archives/systemd-devel/2015-April/030070.html

(I haven't caught up with that yet)

[Simon McVittie (smcv)]

(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 try it. systemd guarantees that /run is a tmpfs, so the "what if I have stale misc lying around in /var/run?" question that we would have had under sysvinit and possibly Upstart does not exist.

> BTW, this is being discussed on the upstream ML too:
>
> http://lists.freedesktop.org/archives/systemd-devel/2015-April/030070.html

I am aware, and have replied there.

[Simon McVittie (smcv)]

(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 patch I posted above (for upstream consumption that would be @DBUS_SYSTEM_PID_FILE@) does work.

[Michael Biebl (mbiebl)]

(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"
>
> ... which does work, but logs "Unit dbus.service entered failed state"
> during shutdown. It seems better to avoid "crying wolf" if possible, because
> it can hide real issues.

Spawning a shell (which will burn more cpu cycles then a simple /bin/true), this will also trigger a failure on every shutdown/reboot.
Do we really want this?

[Lennart-poettering (lennart-poettering)]

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 RefuseManualStop=yes on the unit, but I don't like that much either. It's mostly relevant for things like audit where the kernel might stop if the service is shut down.

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.

[Martin Pitt (pitti)]

(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=dbus units to "After=dbus.service", for the non-kdbus case at least.

[Lennart-poettering (lennart-poettering)]

(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 change the
> implied "After=dbus.socket" for Type=dbus units to "After=dbus.service", for
> the non-kdbus case at least.

Nah, I am pretty sure this should be fixed in the few services that need this, rather than adding these otherwise unnecessary synchronization points to all services, including the ones that don't need it.

[Simon McVittie (smcv)]

(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 RefuseManualStop=yes on the unit, but I don't like that much
> either.

I don't think this would satisfy the original requirement unless the ExecStop=/bin/true was also included, and you've said that that's undesired.

> Please do not apply that ExecStop= thing. You really shouldn't block that.

Fair enough. NOTOURBUG then.

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

OK. In the case of the original bug report, I think this means wpasupplicant and maybe NetworkManager would have to either turn off exit-on-disconnect (for libdbus and/or GDBus, depending which they use), or be After=dbus.service.

[Tommy Vestermark (tov)]

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 /nas nfs noauto,x-systemd.automount,soft,timeo=20,retrans=10 0 0
Un-mounting before shutdown makes it shutdown correctly.

Is this bug still active or should I file a new one?

[CaptainPlanet (captainplanet)]

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.

[Colin Law (colin-law)]

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.

[Adam Felson (adam-ubuntu)]

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.

[stormhike (stormhike)]

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.d
rm K05umountnfs
ln -s ../init.d/umountnfs K05umountnfs

[Alexander Chepurko (alexander-chepurko)]

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

[Adam Felson (adam-ubuntu)]

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/NetworkManager/dispatcher.d/pre-down has a link to it as well.
#!/bin/bash

IF=$1
STATUS=$2
logger -s "********************** NetworkManager dispatch script nfs, IF="$1" STATUS="$2

case "$2" in
 pre-down)
 umount -a -t nfs
 service cups stop
 ;;

 up)
    mount -a -t nfs
 ;;

esac

I do NOT use the systemd automount fstab option as it'll try to automount when this script is trying to dismount the nfs shares.

I also have it stop cups as kubuntu sometimes hangs bringing cups down.

[Tim Passingham (tim-8aw3u04umo)]

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 STATUS=hostname

(after trying to bring up my wifi device which is disabled)

And:

root: ********************** NetworkManager dispatch script nfs, IF=enp2s0 STATUS=up

(on bring up my ethernet network)

But never a Status=pre-down

I am using autofs, but I'm not sure if that's the same as using 'systemd automount fstab'

[Nico Orrù (nigu-orru)]

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

[ALinuxUser (buntulongername-new)]

I suffer from this too. It affects both systemd's automounts and autofs. It's driving me nuts.

[ALinuxUser (buntulongername-new)]

@Adam Felson

I'm trying out your script, combined with autofs (which doesn't work via fstab).

[ALinuxUser (buntulongername-new)]

(But I've removed the cups and the 'up' bits.)

[ALinuxUser (buntulongername-new)]

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.