Bug#761909: systemd does not unmount nfs shares before bringing down the network interface

Control: reassign -1 ifupdown 0.8.5 Control: tag -1 patch Martin Pitt [2016-01-03 16:02 +0100]: > Michael Biebl [2015-12-18 14:55 +0100]: > Am 18.12.2015 um 11:12 schrieb > Martin Pitt: > > I agree that this sounds like an upstream bug. If there is not explicit > > Conflicts=shutdown.target, I

Bug#761909: systemd does not unmount nfs shares before bringing down the network interface

Michael Biebl [2015-12-18 14:55 +0100]: > Am 18.12.2015 um 11:12 schrieb Martin Pitt: > I agree that this sounds like an upstream bug. If there is not explicit > Conflicts=shutdown.target, I don't see why the instance should be > stopped. That would be very inconsistent and unexpected behaviour.

Bug#761909: systemd does not unmount nfs shares before bringing down the network interface

Control: tag -1 upstream Martin Pitt [2015-12-18 9:06 +0100]: > Apparently 228 (or perhaps 227) changed behaviour so that > ifup@.service always gets stopped, even if they have > DefaultDependencies=no and thus no Conflicts=shutdown.target. This applies to any instantiated unit apparenlty.

Bug#761909: systemd does not unmount nfs shares before bringing down the network interface

Control: forwarded -1 https://github.com/systemd/systemd/issues/2189 I now bisected this and understand what's going on. Further details are in the upstream issue. If this was really deliberate and we can't prevent instantiated units from getting stopped during shutdown, then I propose as a

Bug#761909: systemd does not unmount nfs shares before bringing down the network interface

Control: reopen -1 Control: found -1 228-2 This bug is back in 228-2, ifup@.service now again gets stopped during shutdown. Apparently 228 (or perhaps 227) changed behaviour so that ifup@.service always gets stopped, even if they have DefaultDependencies=no and thus no Conflicts=shutdown.target.

Bug#761909: systemd does not unmount nfs shares before bringing down the network interface

Am 18.12.2015 um 11:12 schrieb Martin Pitt: > If this was really deliberate and we can't prevent instantiated units > from getting stopped during shutdown, then I propose as a fallback we > just drop the ExecStop=ifdown (or replace it with some "echo not > supported blabla, please use ifdown

Bug#761909: systemd does not unmount nfs shares before bringing down the network interface

Hello, Giuseppe Bilotta [2014-09-16 20:15 +0200]: > My fstab includes the line > > labrador:/oneforall /oneforallnfs auto,exec 0 0 > > and the nfs share is automatically mounted when a network interface that > can resolve `labrador` is brought up. I don't use NM nor

Bug#761909: systemd does not unmount nfs shares before bringing down the network interface

Am 05.10.2015 um 12:07 schrieb Michael Biebl: > The ifup@.service unit file has DefaultDependencies=no and *no* > Conflicts=shutdown.target, which means it should *not* be stopped on > shutdown. This was done this way for exactly the reason you mention. Originally I designed it that way: no

Bug#761909: systemd does not unmount nfs shares before bringing down the network interface

Am 05.10.2015 um 11:15 schrieb Martin Pitt: > Hello, > > Giuseppe Bilotta [2014-09-16 20:15 +0200]: >> My fstab includes the line >> >> labrador:/oneforall /oneforall nfs auto,exec 0 0 >> >> and the nfs share is automatically mounted when a network interface that >> can

Bug#761909: systemd does not unmount nfs shares before bringing down the network interface

Am 05.10.2015 um 11:15 schrieb Martin Pitt: > Or we just declare that we don't support manual stops, and you are > supposed to run "sudo ifdown ethX" to stop an interface. This is also > reasonable as we consider ifup@.service more like an internal helper > unit, not an user-visible/actionable

Bug#761909: systemd does not unmount nfs shares before bringing down the network interface

Michael Biebl [2015-10-05 12:11 +0200]: > Can someone check if ifup@.service units are stopped on shutdown? I already did this morning before I wrote that reply, they do get stopped. I added an "echo XXX; systemctl is-system-running" to ExecStop=, and I see these on shutdown. Martin -- Martin

Bug#761909: systemd does not unmount nfs shares before bringing down the network interface

Control: tag -1 pending Hello Michael, Michael Biebl [2015-10-05 12:11 +0200]: > Originally I designed it that way: no Conflicts=shutdown.target and > letting networking.service do the clean up on shutdown. > > ifup@.service was changed in the mean time. I wonder if the > PartOf=network.target

Bug#761909: systemd does not unmount nfs shares before bringing down the network interface

Hello On Mon, Oct 5, 2015 at 11:15 AM, Martin Pitt wrote: >> However, when the network is brought down (manually, or automatically >> during system shutdown), the mountpoint is not unmounted, causing a >> number of issues. > > This sounds very similar to

Bug#761909: systemd does not unmount nfs shares before bringing down the network interface

Dear Maintainer,   i am running jessie and I have exactly the same bug as described in post #25. My system is connected to the net by wlan (NM).   Regards,   Jürgen

Bug#761909: systemd does not unmount nfs shares before bringing down the network interface

Am 16.09.2014 um 20:15 schrieb Giuseppe Bilotta: Package: systemd Version: 215-4 Severity: normal My fstab includes the line labrador:/oneforall /oneforallnfs auto,exec 0 0 and the nfs share is automatically mounted when a network interface that can resolve

Bug#761909: systemd does not unmount nfs shares before bringing down the network interface

On Tue, Sep 16, 2014 at 9:06 PM, Michael Biebl bi...@debian.org wrote: Am 16.09.2014 um 20:15 schrieb Giuseppe Bilotta: Most significantly, if I shutdown the system after bringing up the network, the shutdown process will hang while waiting for the un-mounting of /oneforall, which cannot