On 30/07/12 23:36, Dan Williams wrote:...snipOn 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.) Peter Dan _______________________________________________ |