DNS name resolution should not be done during configuration parsing.

[Eryk Wieliczko]

Configuring such things is an additional unnecessary step. OpenVPN/tinc don't require such hacks. Once you start OpenVPN, it's gonna work until the server dies of old age. :-)

This is a problem that's gonna bite some users in the least opportune moment, just like it bit David. And it's a reason why I'm currently using tinc.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, February 17, 2019 5:08 AM, Jeffrey Walton <noloader at gmail.com> wrote:

> On Sat, Feb 16, 2019 at 10:35 PM David Kerr david at kerr.net wrote:
>
> > Erik, see here for a proposed fix. No response from the WireGuard team yet.
> > https://lists.zx2c4.com/pipermail/wireguard/2019-January/003842.html
> > Recently I had a power outage and both my gateway and cable modem went offline. On power recovery both devices start up, but the gateway completes startup before the cable modem completes its protocol negotiations, so initially the external network (eth0) is not functional. That comes online say one minute later and all is well.
> > Except that all is not well. Wireguard failed to start up because I have Endpoint=<a URL> instead of a IP address. And because external interface is not live yet, DNS lookup fails and Wireguard does not gracefully handle it. This is really important because Wireguard may be my only way into my local network.
> > As work-around I replaced the URL with the IP address... but that is not a long term solution if the endpoint is not a static IP address.
> > Wireguard needs to handle the situation where external network may not have stabilized at the time it starts up. The above link proposed a fix.
>
> Forgive my ignorance... Should init just retry the service start?
> Something like this (from Systemd):
>
> [Unit]
> StartLimitInterval=360
> StartLimitBurst=5
>
> The statements above say to retry 5 times within 360 seconds.
>
> Jeff