Re: Problem automatically unmounting VPN shares

[Dan Williams <dcbw redhat com>]

On Tue, 2012-07-31 at 10:22 +0100, Peter Rockett wrote:
> On 30/07/12 23:36, Dan Williams wrote:
> > On Sat, 2012-07-28 at 18:18 -0300, Lamarque V. Souza wrote:
> > > Em Saturday 28 July 2012, Robby Workman escreveu:
> > > On Sat, 28 Jul 2012 12:50:13 +0100
> > > Peter Rockett <p rockett sheffield ac uk> wrote:
> ...snip
> > > 
> > > 
> > > What is happening is that NetworkManager is taking down the connection
> > > before running the dispatch script. That is a known problem.
> > Yes, this is a known issue, and I'm working towards that in the
> > 'dispatcher' branch in git.  That has a rework of a bunch of dispatcher
> > stuff, and the next issue is ensuring that all the cases of terminating
> > a connection via user-request enter the DISCONNECTING state, where
> > "pre-down" stuff would run, before killing the connection completely.
> 
> Great to hear this!
> 
> > 
> > Note that, as I've said before, whatever scripts you use *must* be able
> > to cleanly terminate a failed VPN connection, since this will still
> > periodically happen due to network stupidity and other issues.  We'd
> > expect that choosing 'Disconnect..." from a menu to trigger a clean
> > disconnect, but if your WiFi AP goes out of range or your 3G connection
> > fails, you're out of luck and you need to make sure your script can
> > handle an unexpected disconnect.  NM will help out by making sure these
> > are two separate events, but the script still needs to deal with both.
> 
> Sounds reasonable but despite looking very hard, I never seen this
> good advice given anywhere. Could it be documented somewhere?
> 
> To clarify: I presume my problem is due to an attempt to unmount a
> remote share after the VPN connection has been dropped, resulting in
> the umount command never terminating, so the mount point is 

Likely correct.  SMB has always had this problem too.  Attempting to
"cleanly" unmount the share, which might involve flushing data to the
server, of course will fail or hang because the server can no longer be
contacted.

> permanently locked up? By "handling" you mean that the umount should
> be spawned in the script using timeout and forcibly terminated after x
> seconds? I am unclear in what state that leaves the filesystem? (I ask
> out of ignorance rather than questioning the advice.)

Something like that?  Or a force unmount?  Obviously the share may not
be totally up-to-date, because potentially not all data was written to
it.  But again, that's also something that happens in the real world
when connections randomly drop, so it's something the scripts (and any
remote filesystem, be it SMB or NFS or whatever) needs to deal with by
ensuring that only data is lost, not that filesystem corruption occurs.

Dan