After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 650925 - Consider leaving existing network connections intact on termination
Consider leaving existing network connections intact on termination
Status: RESOLVED DUPLICATE of bug 387832
Product: NetworkManager
Classification: Platform
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Dan Williams
Dan Williams
Depends on:
Blocks:
 
 
Reported: 2011-05-24 01:05 UTC by Mike Perrin
Modified: 2011-05-26 22:22 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Mike Perrin 2011-05-24 01:05:57 UTC
The behavior of NetworkManager to take down managed network connections on termination has caused long shutdown delays in unmounting network shares. The long running Ubuntu bug https://bugs.launchpad.net/bugs/211631 is probably the most notorious example. Although a fix for this specific bug has recently been released, it involves additional complexity in shutdown process coordination. Other distributions have addressed the issue essentially by betting that network share unmounting can win a timing race. The movement away from System V Init to parallel processing has made NM's behavior more difficult to deal with.

On a functional level perhaps it is worth considering whether NetworkManager, on stopping, should simply leave the interfaces as currently configured instead of taking them down. I can make the argument that NetworkManager is a tool to make it easy for the user to control network interfaces, but NetworkManager is not the owner of those interfaces, the system and user are. If the user makes a connection using NetworkManager and then disables NM, why shouldn't the interface stay up until the user or a shutdown sequence takes it down?
Comment 1 Dan Williams 2011-05-25 16:56:47 UTC
This is already done for Ethernet connections that use DHCP or static addressing.  It's not easily possible for WiFi or 3G connections due to the complexities of managing various daemons and re-acquiring state that could have changed drastically while NM was down.

NM 0.9 has new facilities for notifying external entities that it is about to take a connection down, but this support is not yet wired up internally; it's only in the API awaiting for the internal changes.  (NM_DEVICE_STATE_DEACTIVATING)

This support for leaving interfaces up is intended only as a temporary measure for restarting NEtworkManager after an update.  It is not intended for anything else.  This is because if NM is not running important events like DHCP lease changes, WiFi connection state changes, VPN changes, PPP connection drops, IPv6 autoconf RDNSS updates and times, etc can't be handled since nothing is running to handle them.  The network is then left in an inconsistent state.  Many of the daemons that handle the low-level operations here (pppd, pptp, vpnc, dhclient/dhcpcd, avahi-autoipd, etc) don't have any ability to expose their internal state in a way which would allow NM to take these connections over again if it was restarted.

So the clear fix for this issue is to adequately implement the DEACTIVATING state internally and allow the various dispatcher scripts a few seconds or more to clean up after themselves before taking the connection down.
Comment 2 Dan Williams 2011-05-25 17:00:07 UTC

*** This bug has been marked as a duplicate of bug 387832 ***
Comment 3 Dan Williams 2011-05-25 17:03:27 UTC
The other thing I'd add is that network file protocols *NEED* to work correctly when their network resources disappear, because in many cases the connection can be terminated at any point by external events.

So if some service is blocking shutdown waiting on network resources that are no longer reachable, that serivce is incredibly stupid and somebody should beat the crap out of it with a massive cluebat.

Yes, NM should be giving these services a chance to clean up after themselves before taking down the network, but clean shutdown only happens some of the time.  The rest of the time you'll still run into the shutdown hang if e.g. your switch goes down, you walk out of range of your wifi AP, your 3G connection terminates, etc.  And there's nothing NM can really do to help that.
Comment 4 Mike Perrin 2011-05-26 22:22:49 UTC
Dan,

I think you missed the main point of my report, largely my fault because I switched focus from shutdown to user intervention in my second paragraph. My primary concern is the affect from Network Manager taking down interfaces too soon during a system shutdown. In this case, potential changes in network conditions (DHCP lease, WiFi connection state changes, etc.) are irrelevant; the network connections are going down anyway. In that respect I disagree that this is a duplicate of bug 387832 which concerns the interruption of network resources during normal system operation.

Replies to excerpts from your comments:

> This support for leaving interfaces up is intended only as a temporary
> measure for restarting NEtworkManager after an update.  It is not intended
> for anything else.
But such capability could solve the shutdown problem. The init system can ask you politely to go away but leave the network alone, then take the network(s) down in sequence. This would not affect behavior on termination by a user.

> Many of the daemons that handle the low-level operations here (pppd, pptp,
> vpnc, dhclient/dhcpcd, avahi-autoipd, etc) don't have any ability to expose
> their internal state in a way which would allow NM to take these connections
> over again if it was restarted.
It seems logical that starting Network Manager authorizes it to take down any or all interfaces that it manages and start over, which may solve this concern.

> So if some service is blocking shutdown waiting on network resources that are
> no longer reachable, that service is incredibly stupid and somebody should
> beat the crap out of it with a massive cluebat.
Good point. I have never understood why umount screws around for five minutes trying to contact the cifs server. Now where's my cluebat?

> The rest of the time you'll still run into the shutdown hang if e.g. your
> switch goes down, you walk out of range of your wifi AP, your 3G connection
> terminates, etc.  And there's nothing NM can really do to help that.
Agreed. And if you are requested to terminate without taking down the network, you are absolved of responsibility so why worry about it?