Control: fixed -1 2.4.3-1 Control: tags -1 upstream On Wed, Feb 08, 2017 at 06:12:01PM +0100, Serge Pouliquen wrote:
Hi, > When an openvpn client is failing, it gets killed. > > openvpn 2.4 is arriving with a client folder '/etc/openvpn/client/' (and a > server folder). > So I put client files and the server files in their own folder. > > I found that the matching systemd commands are : > systemctl enable openvpn-client@yyy.service > systemctl enable openvpn-server@xxx.service > > At boot, if server is not reachable, the service is killed: > # Feb 7 21:08:57 lemon openvpn[4925]: SIGTERM[hard,init_instance] received, > process exiting > # Feb 7 21:08:57 lemon systemd[1]: openvpn-client@yyy.service: Unit entered > failed state. > # Feb 7 21:08:57 lemon systemd[1]: openvpn-client@yyy.service: Failed with > result 'timeout'. > > Expected result : service not killed > If server is not started/reachable at startup, but became later. I expect the > client to attempt later. openvpn-client@.service and openvpn-server@.service are provided by upstream. They use Type=notify to signal systemd the proper startup. Unfortunately in upstream version 2.4.0 READY=1 is only emitted after the client (or a server in p2p mode) has established the connection. See https://github.com/OpenVPN/openvpn/commit/e83a8684f0a0d944e9d53cdad2b543cfd1b6fbae for the fix. This has been fixed in a later version, but I'm not sure we can backport this sanely without the risk of regressions (i.e. people relying on this behaviour, as seen in #857169). Please use the standard Debian config (/etc/openvpn/xxx.conf, openvpn@xxx.service) Bernhard
