If ntpdate is run when the network is down, it takes a long time before giving up on the DNS lookup for its server(s). I think this is true of anything that does a DNS lookup not ntp specifically. However, I regard this as a small infelicity in the ntp ebuild because nothing else in the boot sequence does this (I imagine that everyone knows to avoid doing anything requiring a lookup at boot time?), and if it can't be fixed by re-writing init.d/ntp-client there is a simple workaround that could be at least demonstrated and documented in init.d/ntp-client. Reproducible: Always Steps to Reproduce: 1. Make sure that ntp-client runs at boot time(is in either the boot or default runlevel), uses ntpdate, and has the FQDN of a couple of working ntp servers. 2. /etc/init.d/ntp-client start to verify it syncs properly. 3. Remove the ethernet cable from the back of the computer (probably anything that causes DNS lookup to fail is sufficient). 4. Reboot. Actual Results: ntp-client hangs for a while for each hostname it tries to look up, finally reporting failure. Expected Results: ntpdate is probably only doing what it must, but the delay with two timeservers is quite bad, and a newbie is likely to think something is wrong. A newbie is precisely the person who may frequently boot when there is no network present, and there is an easy way for the ebuild to help out here. I think it should have another comment line or two warning of this and suggesting that the timeservers IP address be used in the arguments for ntpdate rather than the FQDN. This ensures that the clock is set if it can be but doesn't wait around if it can't. I tried using ntpd -q instead, but it doesn't sync the clock properly so it still seems appropriate to help people using ntp-client for an initial sync.
handled like nfs script handles timeout set NTPCLIENT_TIMEOUT in conf.d/ntp-client, defaults to 30 seconds
