Christopher Ness wrote:
No. ntpd just attempts to run anyway. The initial ntpdate tends to stall for a few seconds if the network connection isn't there, and if that's too much then it's OK to just remove or empty the step-tickers file. I didn't run NTP at all until I had a permanent network connection. Now, however, I have a permanently running server that provides a stratum 3 server for everything else that boots. If the DSL connection goes down then it doesn't much matter from the point of view of NTP.It's not clear to me why you would want to do this when configuring ntpd is so easy -- just run redhat-config-date and check "enable network time protocol".
Won't this stall the machine on boot if a network connection is not
available? Don't be scared of cron. It is quite helpful, and if you
have an application that requires all your machines to be somewhat close
in time then is "enable network time protocol" good enough?
I agree with Tom that everyone should randomize their network accesses
though.
This is why ntp was created in the first place, well, one of the reasons.
What simply fails? chronyd doesn't work do you mean? I remembered another one as well: k9 (kaska.demon.co.uk), although I think that just picks up ntp broadcasts which gives it limited use.
If you want time synchronization on a dial-up connection (where you aren't connected all the time), then there are ntp alternatives that do a good job for that: chrony (http://chrony.sunsite.dk/) for example. Just having npdate change the clock periodically isn't all that good -- note that ntp (and chrony, I expect) use adjtime(2) to speed up or slow down time to keep the clock adjusted.
The above simply fails. If you do not want to recieve emails from cron
about failures (you probably do, unless you are often not connected to
the network) then redirect the output to /dev/null
The magic of computers. There are 8x10^6 ways to do something. ChooseTrue. And about 75% of them break sooner or later. The adjtime() system call was put in place because various applications -- "make" was the main one at the time -- break when they find time has suddenly gone backwards. You can use ntpdate and cron to set the time, but don't complain when things behave badly, if, of couse, you can work out why they broke in the first place.
your weapon and stick with it unless something absolutely better comes
by.
If you really want to run ntpdate to periodically synchronise the time (and I would say that chronyd is still a better choice), then stick at the end of the ifup script so that you only step the time when you bring the dial-up connection up. If you have a permanent connection then just run ntp and forget it.
jch
