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