Em Saturday 28 July 2012, Robby Workman escreveu:
> On Sat, 28 Jul 2012 12:50:13 +0100
>
> Peter Rockett <p.rock...@sheffield.ac.uk> wrote:
> > Hi
> >
> > I am trying to automatically mount and unmount a share at my office.
> > I have a script in /etc/NetworkManager/dispatch.d which runs along
> > the lines:
> >
> > #!/bin/bash
> >
> > case "$2" in
> >
> > vpn-up)
> >
> > exec mount blah-blah-blah
> > ;;
> >
> > vpn-down)
> >
> > exec umount blah-blah-blah
> > ;;
> >
> > esac
> >
> > which mounts the share in my home directory (on Ubuntu 11.10 +
> > Network Manager v. 0.9.1.90). I swear this all worked fine when I set
> > it up in 2010. But some time in the intervening period it has broken.
> > (I am infrequent user of VPN since I got DropBox!) I have also
> > upgraded from Natty to Oneiric in the meantime...
> >
> > Now, VPN connects fine, the remote share is mounted OK. I can
> > see/access all the remote files. But when I disconnect from VPN, the
> > running of the umount seems to go very wrong. After disconnect, if I
> > open a terminal and type "ls" to list the contents of my home
> > directory (the mount point), the "ls" command hangs. (Nautilus also
> > hangs - either it won't start or, if it was running already, it
> > hangs.) Everything else in the OS seems to work OK. It seems for all
> > the world as if the mount point is getting screwed and the only
> > recovery is to restart (in which the shutdown takes much longer than
> > usual).
> >
> > 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.
> 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.
--
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
_______________________________________________
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
