Control: tags -1 wontfix Hi Erik,
first of all, thanks for your detailed analysis. > Mär 09 08:53:47 m2 systemd[1]: Started OpenVPN connection to client. <<< this > is what notifyhelper.sh does! > Mär 09 08:53:47 m2 systemd[1]: Mounting /home... > Mär 09 08:53:47 m2 openvpn[664]: Thu Mar 9 08:53:47 2017 /sbin/ip route del > 0.0.0.0/0 > Mär 09 08:53:47 m2 openvpn[664]: Thu Mar 9 08:53:47 2017 /sbin/ip route add > 0.0.0.0/0 via 192.100.100.1 > Mär 09 08:53:47 m2 openvpn[664]: Thu Mar 9 08:53:47 2017 Initialization > Sequence Completed > > as you see from the journalctl excerpt above, > some routes are set AFTER notifyhelper.sh gets called. > so we have an order problem here. > I do not find a way to specify that notifyhelper.sh must be called VERY LAST. > if I read my logs longer i see that mounting /home fails because the routes > have not been set... > > Second major problem: > > Mär 09 08:53:44 m2 openvpn[664]: Thu Mar 9 08:53:44 2017 Multiple --up > scripts defined. The previously configured script is overridden. > > In my case this leads to the problem that /etc/openvpn/update-resolv-conf > does not get called which is specified from my /etc/openvpn/client.conf file. Only one "up" script is supported. You can hack something locally with either a wrapper script or run-parts(8), but this won't be supported upstream. > Conclusion: > > It does not seem to be easy to make openvpn call some script at the very end > without interfering with the way the user thinks its own config file works > (i.e. the user has his own --up calls there.) > > > > The clean way would be to have openvpn call systemctl sd_notify(...READY=1) > at the absolute end of initialization. upstream someone? In fact upstream has changed this to emit READY=1 a lot earlier than before, which will completely break any assumptions about having an established connection when the systemd unit is running. https://github.com/OpenVPN/openvpn/commit/e83a8684f0a0d944e9d53cdad2b543cfd1b6fbae Unfortunately I don't have any good advise here, but since this is something that cannot be sanely be done in a generic configuration we cannot fix it in Debian, hence marking the bug "wontfix". One possible option could also be to add the routes inside the up script before starting the mount. But again, this would be a very specific local configuration. > meanwhile I will continue by writing a custom systemd service > which waits until openvpn is ready by doing dns lookups and or pings. > then i will add the neccessary dependencies to make my boot work. > But for now I will give up on the idea of doing it the right way. Bernhard
