[ntp:questions] Wrong time after changing hardware

Per Hedeland per at hedeland.org
Tue Jul 24 23:00:38 UTC 2007


In article <f84b16$vak$1 at svr7.m-online.net> Marc Muehlfeld
<marc.muehlfeld at web.de> writes:
>
>Per Hedeland schrieb:
>> Note that the location can also be specified via the commandline (-f
>> option), overriding what is in ntp.conf AFAIK. I.e. check the
>> commandline of your running ntpd too.
>I allready checked. There are no parameters inside the runlevel script for the 
>drift file. It's started with the following options:
>/usr/sbin/ntpd -p /var/lib/ntp/var/run/ntp/ntpd.pid -u ntp -i /var/lib/ntp
>
>
>
> > In any case the driftfile spec you
>> have there is pretty "weird" - I've seen some Linux distros use
>> /var/lib/ntp/drift (i.e. a file called 'drift' in the /var/lib/ntp
>> directory), which makes some sense when running ntpd as non-root, but
>> your pathname is just "stupid" (no offense intended:-).
>The path is just the one out of the box after installing the xntp-4.2.0a-46 
>package from Suse 10.0. The ntpd runs chroot and as user "ntp" by default.

It's still "weird".:-) But anyway, for things to work right when ntpd is
chrooted to /var/lib/ntp, I believe the file if specified as
/var/lib/ntp/drift/ntp.drift in ntp.conf must actually be at
/var/lib/ntp/var/lib/ntp/drift/ntp.drift - if ntpd reads it before doing
the chroot, /var/lib/ntp/drift/ntp.drift should probably be a symlink
pointing to the actual location.

And of course, dealing with the finer details of how various OSes
distribute/install/configure ntpd could be considered somewhat off-topic
here - if there are indications that it isn't working properly, it may
be a good idea to do a more "straightforward" setup first, and once that
is working figure out how to get from there to the "OS-specific" setup
(if desired).

>I also reinstalled and it wasn't touched. But the file is used. When I look at 
>/var/log/messages, I see the following on a restart
>Jul 24 09:32:27 myserver ntpdate[15037]: adjust time server 80.86.83.133 
>offset 0.000961 sec

So there is the reason why time is synced when you "restart ntpd", as I
suspected...

>Jul 24 09:32:27 myserver ntpd[15042]: ntpd 4.2.0a at 1.1191-r Fri Sep  9 17:17:17 
>UTC 2005 (1)
>Jul 24 09:32:27 myserver ntpd[15042]: precision = 1.000 usec
>Jul 24 09:32:27 myserver ntpd[15042]: Listening on interface wildcard,
>0.0.0.0#123
>Jul 24 09:32:27 myserver ntpd[15042]: Listening on interface wildcard, ::#123
>Jul 24 09:32:27 myserver ntpd[15042]: Listening on interface lo, 127.0.0.1#123
>Jul 24 09:32:27 myserver ntpd[15042]: Listening on interface eth0,
>192.168.0.1#123
>Jul 24 09:32:27 myserver ntpd[15042]: kernel time sync status 0040
>Jul 24 09:32:27 myserver ntpd[15042]: frequency initialized 0.000 PPM from 
>/var/lib/ntp/drift/ntp.drift

OK, good so far - but since we have established that the actual drift of
your system is really on the order of 200 ppm, and that it's a bad idea
to lie to ntpd by providing a random value such as 0 in the file, you
should remove the file before starting ntpd. Otherwise it will take ntpd
a "long" time to figure out that the value you (or SuSE if you prefer)
gave was completely wrong, probably including at least one unneeded
reset and stepping of the clock, maybe several.

>> ... the most important info: Output of 'ntpq -p', after ntpd has been
> > running for a significant while.
>I'll send this later. I just restarted shortly ago.

So you should maybe restart again per above.:-) Doesn't hurt to capture
the ntpq output first though, it may still have useful info.

--Per Hedeland
per at hedeland.org




More information about the questions mailing list