On Sat, 28 Jul 2012 18:18:11 -0300 "Lamarque V. Souza" <lamar...@kde.org> wrote:
> Em Saturday 28 July 2012, Robby Workman escreveu: > > > > Peter Rockett <p.rock...@sheffield.ac.uk> wrote: > > > > > > ... snipped ... > > > > > > The weird thing is that, if I delete the dispatcher script above, > > > connect to VPN, mount the drive manually in a terminal, then > > > umount it manually, and disconnect from VPN, everything is fine > > > and as it should be. So it seems like the dispatcher daemon is > > > making a mess of running the unmount... but not the mount. > > > > > > Any ideas where to go with this? > > What is happening is that NetworkManager is taking down the > connection before running the dispatch script. That is a known > problem. Ah, I wasn't aware of that. I don't know if there's a reason for it to occur that way, so I can't say for sure, but that seems less than ideal... > > See mount(8), particularly the -l and -f options: > > > > -f Force unmount (in case of an unreachable NFS system). > > -l Lazy unmount. Detach the filesystem from the filesystem > > hierarchy now, and cleanup all references to the > > filesystem as soon as it is not busy anymore. > > Those options can prevent other programs from hanging. But > keep in mind that nfs clients maintain a local cache that may not > have been sync'ed to the server by the time the connection is taken > down. Files can be corrupted because of that though I have never seen > that happening. I've never seen corruption, but I have had some occasions with the server having stale info (basically, the local cache never got synced to the server, it seems)... -RW _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
