Shutdown sequence and Network filesystems

[Thierry Carrez]

Steve Langasek wrote:
> On Mon, Mar 16, 2009 at 04:24:43PM +0000, Scott James Remnant wrote:
>> On Mon, 2009-03-16 at 15:14 +0100, Thierry Carrez wrote:
> 
>>> To cut those long threads short, the problem is that on
>>> NetworkManager-enabled systems, we kill networking at S20sendsigs,
>>> before S31umountnfs.sh. This leads to various timeout errors in
>>> umountnfs.sh and potentially to data loss on the network filesystems.
> 
>> Since Network Manager, and D-Bus, and HAL, and various other bits of
>> that stack are in /usr - it's kinda hard to *not* kill them and
>> have /usr-on-NFS work.
> 
> It's also kinda hard to have /usr-on-NFS work at all if you're using Network
> Manager to manage that connection, though.

Exactly, you can't really have network maintained by bits in /usr and
/usr on NFS either. I think on NM-enabled desktops, the use case of
mounting a samba share from your music library NAS is more common than
having /usr-on-NFS, and keeping one broken to make sure the other is
properly handled might not be the best response...

If we agree that we can't have both /usr-on-NFS and NetworkManager at
the same time, then the proposed S20sendsigs could detect the two use
cases and act accordingly. If we want to keep the old behavior in all
cases, then I'd argue an option in /etc/default/rcS could be used to
trigger the new behavior (keep selected network-maintaining processes
alive until umountnfs.sh completes).

Or maybe I just missed a more elegant way of fixing it for all use cases ?

Another related bug is openvpn bug 41794, VPN tunnel is closed before
network drives are unmounted when shutting down.

-- 
Thierry Carrez
Ubuntu server team || Canonical Ltd.