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.