Re: Problem automatically unmounting VPN shares

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:

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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]