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

[Martin Pitt]

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 don't see why the instance should be
> > stopped. That would be very inconsistent and unexpected behaviour.
> 
> For the record, I sent an upstream fix for this last week:
> 
>   https://github.com/systemd/systemd/pull/2235

Upstream replied there. This PR was not accepted, and I sympathize
with the reasoning. Instead, Lennart proposed a different solution for
this special case, by just avoiding to run ifup@.service in its own
slice; we don't actually need that, so running it in in the standard
system.slice fixes both this bug and saves a few cycles by not
creating the sub-slice.

Reassigning to ifupdown, as ifup@.service moved there in the meantime.

git am patch attached. Guus, do you want to review those before
committing, or do you want Michael and me to commit updates to the
systemd units directly? (I don't actually think it'll happen that
often, though.)

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
From 745c1938872c8097cbe0b3cee667e97484a1fad8 Mon Sep 17 00:00:00 2001
From: Martin Pitt 
Date: Tue, 12 Jan 2016 21:31:38 +0100
Subject: [PATCH] ifup@.service: Avoid stopping on shutdown via stopping
 system-ifup.slice

This is a small behaviour change in systemd 228, as instantiated units now
Require= their parent slice instead of just Wants= it.

We don't need resource control on the group of ifup@ units, so just let them
run in the normal system.slice; this avoids stopping them on shutdown, as this
interferes with NFS root and isn't necessary as networking.service already
takes care of shutting down interfaces.

Closes: #761909
LP: #1492546
---
 debian/changelog | 2 ++
 debian/ifup@.service | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 1db3cfd..b994004 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,8 @@ ifupdown (0.8.8) UNRELEASED; urgency=medium
 
   * Fix ifquery crash if interface state file does not exist yet.
 (Closes: #810779, LP: #1532722)
+  * ifup@.service: Avoid stopping on shutdown via stopping system-ifup.slice
+(changed behaviour in systemd 228). (Closes: #761909, LP: #1492546)
 
  -- Martin Pitt   Tue, 12 Jan 2016 08:07:23 +0100
 
diff --git a/debian/ifup@.service b/debian/ifup@.service
index a46a591..7de416c 100644
--- a/debian/ifup@.service
+++ b/debian/ifup@.service
@@ -7,6 +7,8 @@ DefaultDependencies=no
 IgnoreOnIsolate=yes
 
 [Service]
+# avoid stopping on shutdown via stopping system-ifup.slice
+Slice=system.slice
 ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifquery --state %I'
 ExecStop=/sbin/ifdown %I
 RemainAfterExit=true
-- 
2.7.0.rc3



signature.asc
Description: Digital signature

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

[Martin Pitt]

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.

For the record, I sent an upstream fix for this last week:

  https://github.com/systemd/systemd/pull/2235

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

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

[Martin Pitt]

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. Easily reproducible
in nspawn with

cat < /etc/systemd/system/letmelive@.service
[Unit]
Description=@@@ Let me live %i
DefaultDependencies=no

[Service]
RemainAfterExit=yes
StandardOutput=journal+console
ExecStart=/bin/true
ExecStop=/usr/bin/touch /nooo
ExecStop=/bin/echo "!!! I GOT KILLED !"
EOF
systemctl daemon-reload
systemctl start letmelive@1.service

and then reboot -- you will see that letmelive@1 gets stopped.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

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

[Martin Pitt]

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 fallback we
just drop the ExecStop=ifdown (or replace it with some "echo not
supported blabla, please use ifdown directly"). Michael, any
objections to that? This is just an internal helper unit for the udev
rule, after all.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

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

[Martin Pitt]

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. I tried
to remove all dependencies from ifup@.service and then it gets stopped
as pretty much the last thing, but it still gets stopped. This will
again break root partition on NFS or iSCSI or similar setups.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

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

[Michael Biebl]

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 directly"). Michael, any
> objections to that? This is just an internal helper unit for the udev
> rule, after all.

The stop action is there, so the device is properly stopped on unplug.
And if we don't stop the unit, it wouldn't work if we re-plugin the
hardware. So I don't think we can easily drop the stop action.

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.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

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

[Martin Pitt]

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 wicd, so I
> bring the network interfaces up myself, typically with something like:
> 
> sudo ifup wlan0=home
> 
> 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 https://launchpad.net/bugs/1492546 .
ifupdown's /etc/init.d/networking (and also /etc/init/networking.conf)
call functions check_network_file_systems() and check_network_swap()
and don't tear down the interface(s) in the above situation. This also
applies to e. g. iscsi.

But we don't do the same with the autogenerated ifup@.service -- that
always unconditionally calls "ifdown" on stopping. IMHO we should make
"systemctl stop ifup@ethX.service" a no-op at least during shutdown,
as stopping /etc/init.d/networking will stop them all anyway (or not,
if network file systems are being used).

We could change the ExecStop= to something like

  /bin/sh -ec '[ "$(systemctl is-system-running)" = stopping ] || /sbin/ifdown 
%I"

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

For sure I don't want to replicate the entire
check_network_file_systems()/check_network_swap() logic in
ifup@.service -- running this once on shutdown is bad enough :-)

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

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

[Michael Biebl]

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

Can someone check if ifup@.service units are stopped on shutdown?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

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

[Michael Biebl]

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 resolve `labrador` is brought up. I don't use NM nor wicd, so I
>> bring the network interfaces up myself, typically with something like:
>>
>> sudo ifup wlan0=home
>>
>> 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 https://launchpad.net/bugs/1492546 .
> ifupdown's /etc/init.d/networking (and also /etc/init/networking.conf)
> call functions check_network_file_systems() and check_network_swap()
> and don't tear down the interface(s) in the above situation. This also
> applies to e. g. iscsi.
> 
> But we don't do the same with the autogenerated ifup@.service -- that
> always unconditionally calls "ifdown" on stopping. IMHO we should make
> "systemctl stop ifup@ethX.service" a no-op at least during shutdown,
> as stopping /etc/init.d/networking will stop them all anyway (or not,
> if network file systems are being used).
> 
> We could change the ExecStop= to something like
> 
>   /bin/sh -ec '[ "$(systemctl is-system-running)" = stopping ] || 
> /sbin/ifdown %I"
> 
> 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 one.
> 
> For sure I don't want to replicate the entire
> check_network_file_systems()/check_network_swap() logic in
> ifup@.service -- running this once on shutdown is bad enough :-)
> 


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.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

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

[Michael Biebl]

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

We bind the unit to the lifetime of the interface, i.e. we want to run
ifdown $iface if the device is unplugged. So I don't think we should
remove the ExecStop, at least not without making sure that this would
cause regressions, like stale ifupdown state files.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

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

[Martin Pitt]

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 Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

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

[Martin Pitt]

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

That's indeed it! I dropped it, and ifup@*.service isn't stopped on
shutdown any more.

The PartOf= has a rather long history: It got introduced in 1afebb7,
immediately reverted in fc63e489, and reintroduced in 3d857c21.

However, with dropping the PartOf=, I just verified that "systemctl
isolate emergency.target" still works fine -- as
/etc/init.d/networking is stopped anyway, all interfaces get stopped,
so we don't need to do that again via ifup@.service.
I dont know why this didn't work back then, or it was just an
oversight. But I dropped the PartOf= again in git now.

Michael Biebl [2015-10-05 12:28 +0200]:
> We bind the unit to the lifetime of the interface, i.e. we want to run
> ifdown $iface if the device is unplugged. So I don't think we should
> remove the ExecStop, at least not without making sure that this would
> cause regressions, like stale ifupdown state files.

Indeed. I think it's fine as it is now, you can stop it manually but
it doesn't stop automatically on shutdown any more.

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

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

[Giuseppe Bilotta]

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 https://launchpad.net/bugs/1492546 .
> ifupdown's /etc/init.d/networking (and also /etc/init/networking.conf)
> call functions check_network_file_systems() and check_network_swap()
> and don't tear down the interface(s) in the above situation. This also
> applies to e. g. iscsi.
>
> But we don't do the same with the autogenerated ifup@.service -- that
> always unconditionally calls "ifdown" on stopping. IMHO we should make
> "systemctl stop ifup@ethX.service" a no-op at least during shutdown,
> as stopping /etc/init.d/networking will stop them all anyway (or not,
> if network file systems are being used).

Shouldn't a dependcy of network filesystems on network interfaces
automatically prevet the network interfaces services from being
stoppable while the network filesystems are up?

-- 
Giuseppe "Oblomov" Bilotta

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

[Jürgen Bausa]

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

[Michael Biebl]

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 `labrador` is brought up. I don't use NM nor wicd, so I
 bring the network interfaces up myself, typically with something like:
 
 sudo ifup wlan0=home
 
 However, when the network is brought down (manually, or automatically
 during system shutdown), the mountpoint is not unmounted, causing a
 number of issues.
 
 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 happen because the network has
 been automatically brought down already earlier in the shutdown process.


What/which service is responsible for bringing down the network?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

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

[Giuseppe Bilotta]

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 happen because the network has
 been automatically brought down already earlier in the shutdown process.

 What/which service is responsible for bringing down the network?

I have no idea. How do I check that?


-- 
Giuseppe Oblomov Bilotta


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org