[ntp:questions] ntpdate removal is coming

Chad.Farmer at Bull.com Chad.Farmer at Bull.com
Mon Dec 19 23:14:40 UTC 2011


Thanks to everyone for the responses, lots of good information and things 
to consider, particularly chrony and orphan.  In return I think I should 
reply to your questions.

>you are using an old version of ntp.

Yes, I'm using RHEL5.3 (ntp-4.2.2p1-9.el5) and in the process of moving to 
RHEL5.7 (ntp-4.2.2p1-15.el5).  For this thread I would rather not get into 
all that.

>Why are you running a LOCAL refclock?  This is the reason it is taking 
you 20 minutes to sync when you have found another time source.
>You should not be using the Undisciplined Local Clock (127.127.1.x, aka 
"LOCAL") unless this ntpd must be able to serve time to others when no 
real time sources are available.

Yes, I need to distribute a consistent time (even if somewhat incorrect) 
to several systems on a local LAN (without DNS or Internet access). 
Timeservers are accessed on the "ntpd system" through a different LAN 
(normally they are accessible).  The "local LAN" systems do not have 
access to the other LAN.

The default ntp.conf file in RHEL5.7 contains the following lines:

     # Undisciplined Local Clock. This is a fake driver intended for 
backup
     # and when no outside source of synchronized time is available.
     server  127.127.1.0     # local clock
     fudge   127.127.1.0 stratum 10

I did not change these lines, hoping that the high stratum number would 
prevent use of the local clock by ntpd except when network time servers 
are unavailable.  Not sure why the existence of a stratum 10 time source 
would cause a 20 minute delay before issuing a "time reset", but  I 
confess I don't know whether the "local clock" is the timer-interrupt 
driven system time. the "CMOS" time of day clock (hardware clock) or some 
other hardware clock source.

>Is there a reason to not use orphan instead in that case?
I was not aware of it.  Apparently orphan is an improved alternative to 
the local clock that can be used instead of the local clock when access to 
timeservers is lost.  So I need to check it out.

>GUI
Thanks for the warning on the Gnome GUI.  In this case I control what is 
in /etc/ntp.conf for these servers and do not use a GUI.

>Try running your system 24x7!  If you can't do that, try a program 
>called "chrony".  NTPD was never intended for "off again, on again" 
service!

Well for me 24x7 still means booting once or twice a year, at least to 
install software updates.  Test systems are booted much more often, but 
are less critical (unless the time issue messes up tests).

I was not aware of chrony since it is not in RHEL5, but I see that it is 
now in Fedora, so I can take a look.

Using the RedHat service script packaging, I added -x to OPTIONS in 
/etc/sysconfig/ntpd and sett SYNC_HWCLOCK=yes.  This causes the ntpd start 
script to run an ntpdate command followed by a hwclock command (to update 
the "CMOS" clock), before starting ntpd.  This only adds a few seconds to 
the boot.

Even though the existence of local clock causes ntpd to take 20 minutes to 
become confident of the correct time, running ntpdate before ntpd starts 
means that when ntpd figures out what time it is, the difference is likely 
to be within the skew time so that a "time reset" is not needed.

Is there any problem with using this approach?

I agree that systems should not lose time across a boot, but it happens. 
Further, the "CMOS" clock's resolution is one second.  I'm not sure that 
as Linux starts, it waits for a tick before setting the time from that 
clock.  Not handling that correctly would introduce a 1/2 second error (on 
average).



More information about the questions mailing list