Re: Time Sync
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
>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?
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.
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.
>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
by.
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.
jch