Unmount network share before VPN connection is closed?

[AaylaSecura]

Greetings! I have set up a VPN connection using pptpclient-1.7.2-r3 and I mount a share on the remote network using mount -cifs. It works great, apart from when I lose internet connection. The VPN connection is terminated, but my share is not unmounted. I can write a script that will monitor if I have connection and unmount the share if i don't, trouble is if the share is unmounted after the tunnel is closed, it refuses to mount once the VPN is established again (it does not give any error whatsoever). If I leave the share mounted while the tunnel is not open, all filesystem monitoring apps freeze (including the terminal if I try to list the contents of the parent directory where the share is mounted). Is there any way I can tell pptpclient to unmount the share before it brings down the connection (/etc/ppp/ip-down is executed after the connection is closed) ?

[Small_Penguin]

Symlink /etc/init.d/net.ppp0 to net.lo and configure it in /etc/conf.d/net. See net.example coming with openrc. You can define pre_up/pre_down functions in the conf file that does what you want.

BTW: The freezes resolve themselves after some CIFS timeout has been reached. This takes from a few seconds up to a minute or so. I never found out how to work around that.

[AaylaSecura]

Hi and thanks for replying! I tried your suggestion, but it didn't work. The predown() function is executed before ppp0 dies, but it is still executed after pptpclient closes this tunnel (before it brings down the whole interface).
This freezing does indeed resolve itself (provided I lazily unmount the share) after quite some time though. Is there a way I can set this timeout to some smaller value or is that governed by the remote network's settings?

[Small_Penguin]

[AaylaSecura]

I looked at the stop() function and predown() is called at the very beginning (I even tried placing the umount command explicitly at the beginning), but the share still hangs and refuses to unmount. How come net.lo does not handle this and pptpclient gets to close its tunnels before sending a notification it's about to go down?

[Small_Penguin]

Ok, I've missed a bit you've said in the beginning: "It works great, apart from when I lose internet connection."

If connection is lost, that is all out of control of pptp-client or openrc net. It's already too late to close/unmount any connection, no communication takes place with the server. You have to look for a solution to fix the long timeout, or handle the remounting more gracefully. CIFS tries to reconnect automatically IIRC. Try unmount options -l -f. If it's feasible, you might try to reconnect with pptp, then unmount, then disconnect again. Really ugly, but it could work and speed things up for reconnect.

[AaylaSecura]

Oops, that was my bad - I did not mention in my latest post that when I was testing all of this, I was closing the tunnel with poff <tunnel_name> instead of disconnecting from the internet (as if I lose connection). Only now did I realise that this is closing the tunnel directly (that is why net has no control) and is not necessarily bringing the ppp0 interface down (it's brought down, afterwards, cause there was only one open tunnel). So I should have brought the interface down with ifdown instead and let it close all the tunnels.
But that would not solve the issue if I actually lose connection.
I wrote a script that is running constantly and pinging a url every 5s, so if I lose connection it unmounts the share (with the -l option, cause the -f option keeps returning that the share is in use) and closes the tunnel. This solves the freeze after the first timeout (whereas if I don't unmount it at all, it keeps trying to connect and freezes). It's not very efficient, so I will keep looking for another way.
I am wondering why force unmouting it does not work, I thought the -f option was precisely for offline network shares, yet it keeps complaining the share is in use, but there is no process using it...