jch at thehaxbys.co.uk
Tue Mar 2 15:46:37 UTC 2004
Christopher Ness wrote:
>>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
>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?
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
>I agree with Tom that everyone should randomize their network accesses
This is why ntp was created in the first place, well, one of the reasons.
>>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
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.
>The magic of computers. There are 8x10^6 ways to do something. Choose
>your weapon and stick with it unless something absolutely better comes
True. 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.
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.
More information about the users