with constructive criticism/input from a number of net folk, version .0002! randy --- an ntpd config hint 2004.05.20 executive summary o if you have a recent ntpd, use `ntpd -g`, and be sure to start it before you go multiuser if you have clock lock security in multiuser o if the above does not work for you, sorry, you need to read on; you may want to anyway many applications need to be run in host environments where an accurate clock is needed. this is why most hosts today chime with ntp. but, ntpd will not work if your clock is off by a few minutes. it quits or just sits there forever with its finger in its ear. so, newer versions of ntpd have the -g parameter, which allows for a big first step. this obviates the use of ntpdate in the next paragraphs. but, this will not work if you have told the kernel to refuse to change the time when the system is in multiuser mode for security reasons. at boot, before you start ntpd, you can use ntpdate to whack your system's time from a list of friendly nearby and very sure to be connected chimers. if ntpdate takes a minute and thus adds to your boot time, then something is wrong anyway; fix it. in case your dns resolver is slow, servers are in trouble, you're running ntpdate before dns resolution is up [0], etc. have an entry for your ntpdate chimer(s) in /etc/hosts. yes, i too hate /etc/hosts; but i have been bitten without this hack; named is even more fragile than ntpd. run ntpdate -b with a list of servers. this will help if one or more are unreachable. once ntpdate has run, then and only then, start your ntpd. and read all the usual advice on configuration, selection and solicitation of chimers with which to peer, ... the 'iburst' keyword for servers listed in ntp.conf will cause ntpd toperform an initial sync (defined as any synchronization after a transition out of an unsynchronized state) with a short burst of packets in a small interval. so, you get a faster clock update for a small tradeoff in accuracy. not considered polite to public servers, but if you have local boxes that keep pretty good time, it's may be worth the minute amount of extra traffic. and then, if having accurate time on this host is critical, cron a script which runs `ntpq -p` and pipes it to a hack which looks to be sure that one of the chimers has a splat in front of it. run this script hourly, and scream bloody hell via email if it finds problems. for more info, see <http://twiki.ntp.org/>. Thanks to Rob Foehl Brad Knowles Peter Lothberg Kevin Oberman Saku Ytti --- [0] - if dnssec is deployed, somewhat accurate time will be needed before name resolution will work. so, if you are an optimimst, expect to see ntpd up before named more and more in the future -30-