Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#52654 - [openvpn] reconnect permanently fails on temporary DNS issues or due to max-clients rule

Attached to Project: Arch Linux
Opened by David Runge (dvzrv) - Saturday, 21 January 2017, 07:11 GMT
Last edited by David Runge (dvzrv) - Sunday, 13 September 2020, 12:15 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Christian Hesse (eworm)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


As openvpn is meant to be a long running process, that will have to (try to) reconnect no matter what, I strongly encourage the maintainers to add "Restart=on-failure" to both service files in the package, as the above mentioned behavior can otherwise not be guaranteed.

Additional info:
openvpn 2.4

Steps to reproduce:
Scenario 1:
1. Configure and enable working openvpn client connection (relying on domain name resolution for the server in use) on system.
2. Start computer in a network with misconfigured DNS.
3. Wait until the service permanently fails.
4. Change to network with working DNS (no reconnect attempts).

Scenario 2:
1. Configure and enable working openvpn client connection on system.
2. Configure server side to only allow one client with the given credentials (max-clients 1).
3. Even with standard keepalive settings (keepalive 10 120) it might now happen, that your client with standard connect-retry (connect-retry 5 300) settings will end up failing to often, before the client is allowed to connect again (because the other, now dead connection was finally dropped) and make systemd kill the service permanently.
This task depends upon

Closed by  David Runge (dvzrv)
Sunday, 13 September 2020, 12:15 GMT
Reason for closing:  Upstream
Additional comments about closing:  Upstream fixed this with cket/827
Comment by Doug Newgard (Scimmia) - Saturday, 21 January 2017, 15:34 GMT
All of these are upstream issues.
Comment by David Runge (dvzrv) - Saturday, 21 January 2017, 16:36 GMT
@Scimmia: Why do you think that?

However that may be, systemd has Restart=on-failure to deal with these kinds of situations.
openvpn connections are long-running processes that should be retried until you switch them off manually and not fail permanently and require a manual restart (because in worst case, you won't be able to do that anymore).

Probably also Restart=on-abnormal would be sufficient. In any case, this is something that should be caught by the service file, that Arch ships, as it otherwise can lead to serious issues with connectivity to important infrastructure.
Comment by Doug Newgard (Scimmia) - Sunday, 22 January 2017, 00:00 GMT
The service files come from upstream, not from Arch.
Comment by David Runge (dvzrv) - Monday, 23 January 2017, 10:02 GMT
@Scimmia: Sorry, didn't have a look in the ABS first.

I added an upstream ticket with a patch:

"Restart=on-abnormal" seems to be sufficient (if anyone's interested).