Shutdown sequence and Network filesystems

[Steve Langasek]

On Mon, Mar 16, 2009 at 03:14:34PM +0100, Thierry Carrez wrote:
> There are three ways of handling your network:

> 1- Without using NetworkManager
> Then everything works fine :)

> 2- With Networkmanager with connection in "Available for all users" mode
> S20sendsigs kills NetworkManager, dhclient and wpasupplicant, resulting
> in loss of network connection. S31umountnfs.sh fails with various
> timeouts/errors.

> 3- With NetworkManager with connection in default mode (per-user)
> When Gnome session is terminated, the network connection is killed... by
> design. So umountnfs.sh fails as well.

> Should we support option (3), mounting network filesystems on a network
> connection in per-user mode ? It seems bound to failure by design. At
> that point I would say it probably makes sense to fix it for option (2)...

There was some impromptu discussion on IRC yesterday about this, and it was
suggested to explore whether this could be handled using a default interface
if-down.d script.  The script would have to:

 - determine the IP address of the network mount
 - establish that this interface is the only interface providing the route
   used for the mount
 - do something sensible <handwave> if the mount point is still in use

That would mostly address case 3, but may give unpleasant results in the
event of a weak wireless signal or due to roaming between multiple APs,
since AFAIK NM will take down the IP configuration whenever it loses
association.  We probably don't want network mounts to automatically come
undone whenever this happens.  (OTOH, it would certainly be nice if
something sensible was done with NFS mounts that I've left mounted before
suspending, and resumed in a completely different network.)

Regardless, my understanding is that the biggest problem with unmounting
network mounts when the network is already gone is with CIFS mounts.  We
should not have to wait for a network timeout on unmount when the network is
demonstrably Not There; this is a bug in the CIFS kernel driver that should
be fixed, regardless of any other changes.

On Tue, Mar 17, 2009 at 10:13:50AM +0000, Scott James Remnant wrote:
> On Tue, 2009-03-17 at 08:48 +0100, Thierry Carrez wrote:

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

> I'm not sure I agree with this.

> Network Manager is aimed sufficiently at the desktop case that accessing
> things like samba shares are more likely to be handled via the GVfs
> layer (ie. smb:/// in nautilus) than by making mounts.

I think that's less about NetworkManager's aim than its reach.  Certainly,
some past comments from Alexander suggest that the long-term goal is to
supplant ifupdown rather than to coexist with it.

And kernel-level cifs mounts may be a minority use case, but we still should
account for them in our design, because it's a very *significant* minority
use case, particularly for large site deployments with central fileservers
for user data.  gvfs smb:// doesn't help very much for getting the user's
homedir mounted.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org