OpenVPN server serivce doesn't restart on `SIGTERM[soft,tls-error]`
Description:
OpenVPN hitting SIGTERM[soft,tls-error] received, process exiting and exiting shows as "Initialization Sequence Completed" and status=0/SUCCESS under systemctl status openvpn-server@config.service which uses Restart=on-failure preventing this site to site VPN link from recovering in the event of ISP network maintenance for example.
In my case I have two sites configured as mode p2p with each-other set as their remotes and bind so they will listen for the other side if it wants to initiate a connection later down the line. But because the remote side never recovers from network downtime (systemd service saw exit code 0) the link regularly goes down without automatically recovering on its own asap.
For me this is caused by TLS Error: TLS key negotiation failed to occur within 60 seconds and TLS Error: TLS handshake failed when the remote cannot be reached. The openvpn process exits with SIGTERM[soft,tls-error] received, process exiting and does not recover automatically, which I feel it should.
Checking with systemctl status openvpn-server@p2p.service shows Status: "Initialization Sequence Completed" and Main PID: 1387833 (code=exited, status=0/SUCCESS) which is not true and prevents the service from restarting. I think this is due to the use of Restart=on-failure expecting a non-zero exit code for resetting.
Would it be a good idea to change this service generator to Restart=always? I cannot think of a real world situation where I want the openvpn-server service on some remote router to exit and for systemd to decide it shouldn't be restarted because of a 0 exit code it detected. An OpenVPN daemon exiting is never good news but systemd seems to treat exit codes of 0 as not needing to be restarted.
I feel this should be Restart=always so that any config run with openvpn-server can recover on its own. Unless someone manually issues systemctl stop it should be able to recover.
I can probably set --hand-window to a ridiculous year-long value as a workaround but it doesn't seem like the right long term solution.
Additional info:
- package version(s)
openvpn 2.6.6-1
- config and/or log files etc.
NA
- link to upstream bug report, if any
None
Steps to reproduce:
Make an OpenVPN server conf with an unreachable remote (Simulating no Internet/path to said remote) and wait for OpenVPN's default TLS handshake timeout of 60 seconds. The process exits, but when started with service openvpn-server@configname.service it will not be restarted.