1 |
On Fri, Nov 22, 2013 at 03:44:42PM -0800, Paul B. Henson wrote: |
2 |
> I've tested a variety of scenarios, from the network interface being |
3 |
> down/unplugged, providing invalid NTP servers, etc., and I haven't |
4 |
> seen a delay longer than 15 seconds. |
5 |
|
6 |
I tracked down the failure mode where openntpd will take forever to |
7 |
start. If you use host names in your config rather than IP addresses, |
8 |
and dns lookups fail, there's a scenario where it will just sit there |
9 |
repeatedly making dns lookups until the end of time 8-/. Basically, the |
10 |
15 second timeout in the current version only checks for the timeout to |
11 |
lapse while waiting for a response from the unpriv'd child process. If |
12 |
the child process has an ntp server to ask for the time, and it takes |
13 |
more than 15 seconds to get a response, the parent gives up on the |
14 |
initial time setting and backgrounds. |
15 |
|
16 |
However, in this failure scenario, the child asks for a dns lookup, the |
17 |
parent times out trying and tells the child sorry no go, and then the |
18 |
child asks again. And again. There is never a 15 second period where the |
19 |
child is unresponsive, the delay is always in the parent waiting for the |
20 |
dns lookup. |
21 |
|
22 |
Bug 493358 has a patch to fix this. With the patch, openntpd will |
23 |
background within approximately 15 seconds plus however long your |
24 |
resolver is configured to take to timeout a dns query. |
25 |
|
26 |
Perhaps now we can just ditch the syslog use flag and remove the option |
27 |
to run in debugging mode with stderr redirected? I don't think there was |
28 |
any need for it other than to resolve the delayed startup bug, which I'm |
29 |
reasonably confident this does... |