Mailing List Archive

how to keep time current, ntp doesn't work
How can I keep the date/time on my system current? Ntp hasn't been
doing it's job. I read somewhere on the forums that ntp doesn't work
when the system is under heavy load. I'm guessing that's what's
happening here since the system runs at 99% cpu quite often.....

Shoudn't the date stay correct if I just use ntp-client and set it
once? It was ntpd that had the problem.

-Josh

--
gentoo-user@gentoo.org mailing list
Re: how to keep time current, ntp doesn't work [ In reply to ]
On Wednesday 20 October 2004 10:56, Josh Close wrote:
> How can I keep the date/time on my system current? Ntp hasn't been
> doing it's job. I read somewhere on the forums that ntp doesn't work
> when the system is under heavy load. I'm guessing that's what's
> happening here since the system runs at 99% cpu quite often.....
>
> Shoudn't the date stay correct if I just use ntp-client and set it
> once? It was ntpd that had the problem.
>
> -Josh
>
> --
> gentoo-user@gentoo.org mailing list

yes, i have been having the same trouble when i'm using my proc heavily. ntp
changes your time in miliseconds, not like ntp-client which just sets the
time to the exact time, so if you your proc is running at 99% it wil slow
down the time a lot more than ntp can set it back right.

my advice would be to run ntp-client in a cron job (hourly is what you
probably want)

-cos

--
In Linux We TrUsT !

--
gentoo-user@gentoo.org mailing list
Re: how to keep time current, ntp doesn't work [ In reply to ]
On Wed, 20 Oct 2004 11:26:09 -0400, Casper the Friendly Ghost
<casper@camelot.homelinux.com> wrote:
> my advice would be to run ntp-client in a cron job (hourly is what you
> probably want)

Thanks. I put ntpdate in a cron job. The time gets skewed when ntpd
isn't running also. Not by a day like with ntpd, but a few mins every
hour.

-Josh

--
gentoo-user@gentoo.org mailing list
Re: how to keep time current, ntp doesn't work [ In reply to ]
Josh Close wrote:

>On Wed, 20 Oct 2004 11:26:09 -0400, Casper the Friendly Ghost
><casper@camelot.homelinux.com> wrote:
>
>
>>my advice would be to run ntp-client in a cron job (hourly is what you
>>probably want)
>>
>>
>
>Thanks. I put ntpdate in a cron job. The time gets skewed when ntpd
>isn't running also. Not by a day like with ntpd, but a few mins every
>hour.
>
>-Josh
>
>

You probably only want to run ntpdate upon system startup and then have
ntpd keep the system time sync and NEVER run ntpdate. Especially if you
run a database. The problem is that ntpdate changes the system time, so
it is possible to skip time or it is possible to repeat time (two
separate and distinct sequential events can happen at the same time as
far as the database is concerned if the date is set in this way). ntpd
takes the approach of slowing or speeding the clock to keep the time
sync, thus, there is no abnormal change in time that can cause the type
of error I mention above.

In short, the common approach is to run ntpdate at startup and to follow
with starting the ntpd daemon to keep the time synced from that point
forward.

--
Thomas T. Veldhouse
Key Fingerprint: 2DB9 813F F510 82C2 E1AE 34D0 D69D 1EDC D5EC AED1
Spammers please contact me at trap@veldy.net.
Re: how to keep time current, ntp doesn't work [ In reply to ]
Josh Close wrote:

>How can I keep the date/time on my system current? Ntp hasn't been
>doing it's job. I read somewhere on the forums that ntp doesn't work
>when the system is under heavy load. I'm guessing that's what's
>happening here since the system runs at 99% cpu quite often.....
>
>Shoudn't the date stay correct if I just use ntp-client and set it
>once? It was ntpd that had the problem.
>
>
>
Perhaps you can post the output from "ntpdc -p ". I suspect you
probably had your daemon incorrectly configured. Here is what is
running on my server:

[veldy@fuggle veldy]$ ntpdc -p
remote local st poll reach delay offset disp
=======================================================================
=host1.com xxx.xxx.xxx.xxx 3 1024 377 0.06046 -0.011108 0.01482
*host2.com xxx.xxx.xxx.xxx 2 1024 377 0.07133 0.008422 0.01483


I munged the hostname to protect those who give permission to use their
ntp services and I munged the local to avoid the bots.

--
Thomas T. Veldhouse
Key Fingerprint: 2DB9 813F F510 82C2 E1AE 34D0 D69D 1EDC D5EC AED1
Spammers please contact me at trap@veldy.net.
Re: how to keep time current, ntp doesn't work [ In reply to ]
On Wed, 20 Oct 2004, Casper the Friendly Ghost wrote:

> my advice would be to run ntp-client in a cron job (hourly is what you
> probably want)

The docs say every hour or two is enough.

The problem with that is that it probably gets unfriendly to your servers
if very many people do it--people inevitably choose the same intervals and
if enough people get in sync the server gets hammered on, say, an hourly
basis. We want to be nice to the public servers and not turn ntp into a
kind of ddos attack so they don't go away (There was a recent problem
discussed on the public pool mailing list where a router (I think)
firmware upgrade inadvertently caused a lot of the things to get in sync,
and some people were pulling or thinking of pulling their servers from the
pool because of the bandwidth). ntpd knows enough to randomly vary its
update time so that clients can't stay in sync.

I'm no ntp expert, but just to make sure: if ntp can't discipline the
clock it's supposed to quit with a message in the system logs. Did you
search your logs for cries for help? Also make sure that the clock is
being set properly at bootup with a single ntpdate or ntpd -q [-g] call.
I found out the hard way that if this isn't happening, the clock is likely
to be off sufficiently far that it will panic and die rather than go into
sync.

Looking at the docs, -N and -P allow you to set the priority of the ntpd
process. Try running it at a high enough priority that it gets the
timeslices it wants even when your load average is high--after all, ntpd
doesn't consume many resources so you probably won't care how high its
priority is. This might be a good possibility to note somewhere for
Gentoo in general, since some people end up doing hours- or days-long
builds.

Dustin


--
gentoo-user@gentoo.org mailing list
Re: how to keep time current, ntp doesn't work [ In reply to ]
On Wed, 20 Oct 2004 15:08:49 -0500, Thomas T. Veldhouse <veldy@veldy.net> wrote:
> In short, the common approach is to run ntpdate at startup and to follow
> with starting the ntpd daemon to keep the time synced from that point
> forward.
>
> --
> Thomas T. Veldhouse

Problem with that is, nptd goes out of sync by more than 12 hours within a day.

-Josh

--
gentoo-user@gentoo.org mailing list
Re: how to keep time current, ntp doesn't work [ In reply to ]
On Wed, 20 Oct 2004 15:12:39 -0500, Thomas T. Veldhouse <veldy@veldy.net> wrote:
> Perhaps you can post the output from "ntpdc -p ". I suspect you
> probably had your daemon incorrectly configured. Here is what is
> running on my server:

Hmm.... I get this

localhost: timed out, nothing received
***Request timed out


Can you post your ntp.conf file? I'm using basically the default conf
that came with the install.

-Josh

--
gentoo-user@gentoo.org mailing list
Re: how to keep time current, ntp doesn't work [ In reply to ]
On Wed, 20 Oct 2004 13:19:40 -0700 (PDT), Dustin
<laurence@alice.caltech.edu> wrote:
> The docs say every hour or two is enough.
>
> I'm no ntp expert, but just to make sure: if ntp can't discipline the
> clock it's supposed to quit with a message in the system logs. Did you
> search your logs for cries for help? Also make sure that the clock is
> being set properly at bootup with a single ntpdate or ntpd -q [-g] call.
> I found out the hard way that if this isn't happening, the clock is likely
> to be off sufficiently far that it will panic and die rather than go into
> sync.

Yes, I have ntp-client starting at default, then ntpd starts.

>
> Looking at the docs, -N and -P allow you to set the priority of the ntpd
> process. Try running it at a high enough priority that it gets the
> timeslices it wants even when your load average is high--after all, ntpd
> doesn't consume many resources so you probably won't care how high its
> priority is. This might be a good possibility to note somewhere for
> Gentoo in general, since some people end up doing hours- or days-long
> builds.
>
> Dustin

I'll have to give the -N a try.

-Josh

--
gentoo-user@gentoo.org mailing list
Re: how to keep time current, ntp doesn't work [ In reply to ]
On Wednesday 20 October 2004 16:08, Thomas T. Veldhouse wrote:

> In short, the common approach is to run ntpdate at startup and to follow
> with starting the ntpd daemon to keep the time synced from that point
> forward.


I believe that he has been doing that but it still falls behind, which is why
he was asking for advice.

-cos

--
In Linux We TrUsT !

--
gentoo-user@gentoo.org mailing list
Re: how to keep time current, ntp doesn't work [ In reply to ]
Josh Close wrote:

>On Wed, 20 Oct 2004 15:12:39 -0500, Thomas T. Veldhouse <veldy@veldy.net> wrote:
>
>
>>Perhaps you can post the output from "ntpdc -p ". I suspect you
>>probably had your daemon incorrectly configured. Here is what is
>>running on my server:
>>
>>
>
>Hmm.... I get this
>
>localhost: timed out, nothing received
>***Request timed out
>
>
>Can you post your ntp.conf file? I'm using basically the default conf
>that came with the install.
>
>-Josh
>
>
>
Well, you will have to find a ntp server that allows you to use it. But
I will munge the hostnames below.

server ntp.host1.com
server ntp.host2.com
driftfile /etc/ntp.drift
logfile /var/log/ntpd.log


Then, in my ntpd.log file:

16 Sep 02:45:58 ntpd[3393]: synchronized to xxx.xxx.xxx.xxx, stratum=3
16 Sep 02:46:01 ntpd[3393]: synchronized to xxx.xxx.xxx.xxy, stratum=2
16 Sep 10:46:55 ntpd[3393]: kernel time sync enabled 6001
16 Sep 11:04:01 ntpd[3393]: kernel time sync enabled 2001
16 Sep 12:55:02 ntpd[3393]: kernel time sync enabled 6001
16 Sep 13:46:17 ntpd[3393]: kernel time sync enabled 2001
16 Sep 15:11:42 ntpd[3393]: kernel time sync enabled 6001
16 Sep 15:28:45 ntpd[3393]: kernel time sync enabled 2001
16 Sep 16:37:01 ntpd[3393]: kernel time sync enabled 6001
16 Sep 16:54:07 ntpd[3393]: kernel time sync enabled 2001

and my 'ntpdc -p' output:

remote local st poll reach delay offset disp
=======================================================================
=ntp.host1.com aaa.bbb.ccc.ddd 3 1024 377 0.05984 0.000430 0.01483
*ntp.host2.com aaa.bbb.ccc.ddd 2 1024 377 0.05783 0.007162 0.01482
Re: how to keep time current, ntp doesn't work [ In reply to ]
On Wed, 20 Oct 2004 17:34:32 -0500
"Thomas T. Veldhouse" <veldy@veldy.net> wrote:

> Josh Close wrote:
>
> >On Wed, 20 Oct 2004 15:12:39 -0500, Thomas T. Veldhouse <veldy@veldy.net> wrote:
> >
> >
> >>Perhaps you can post the output from "ntpdc -p ". I suspect you
> >>probably had your daemon incorrectly configured. Here is what is
> >>running on my server:
> >>
> >>
> >
> >Hmm.... I get this
> >
> >localhost: timed out, nothing received
> >***Request timed out
> >
> >
> >Can you post your ntp.conf file? I'm using basically the default conf
> >that came with the install.
> >
> >-Josh
> >
> >
> >
> Well, you will have to find a ntp server that allows you to use it. But
> I will munge the hostnames below.
>
> server ntp.host1.com
> server ntp.host2.com
> driftfile /etc/ntp.drift
> logfile /var/log/ntpd.log

the "best practice" is to use pool.ntp.org two or three times as your
servers.

This helps spread load.

There are also country variants, for instance I use nz.pool.ntp.org to
get some more local servers.

>
>
> Then, in my ntpd.log file:
>
> 16 Sep 02:45:58 ntpd[3393]: synchronized to xxx.xxx.xxx.xxx, stratum=3
> 16 Sep 02:46:01 ntpd[3393]: synchronized to xxx.xxx.xxx.xxy, stratum=2
> 16 Sep 10:46:55 ntpd[3393]: kernel time sync enabled 6001
> 16 Sep 11:04:01 ntpd[3393]: kernel time sync enabled 2001
> 16 Sep 12:55:02 ntpd[3393]: kernel time sync enabled 6001
> 16 Sep 13:46:17 ntpd[3393]: kernel time sync enabled 2001
> 16 Sep 15:11:42 ntpd[3393]: kernel time sync enabled 6001
> 16 Sep 15:28:45 ntpd[3393]: kernel time sync enabled 2001
> 16 Sep 16:37:01 ntpd[3393]: kernel time sync enabled 6001
> 16 Sep 16:54:07 ntpd[3393]: kernel time sync enabled 2001
>
> and my 'ntpdc -p' output:
>
> remote local st poll reach delay offset disp
> =======================================================================
> =ntp.host1.com aaa.bbb.ccc.ddd 3 1024 377 0.05984 0.000430 0.01483
> *ntp.host2.com aaa.bbb.ccc.ddd 2 1024 377 0.05783 0.007162 0.01482
>
>
>
>
>

--
Nick Rout <nick@rout.co.nz>


--
gentoo-user@gentoo.org mailing list
Re: how to keep time current, ntp doesn't work [ In reply to ]
On Wed, 20 Oct 2004, Josh Close wrote:

> Problem with that is, nptd goes out of sync by more than 12 hours within a day.

Then it is not running, because (unless you change the value) it panics
and quits when it is more than (hmm, from memory, check the docs) several
minutes off.

Granted, it is possible that ntpd is really failing, but I am pretty sure
that what is happening is that it never got started in the first place.
There are several ways this can happen. I'm not saying ntpd can't fail
(your clock sounds astoundingly bad--50% error?!?--and might give ntpd
more trouble), but the odds are it's a configuration issue. I suggest you
assume it is misconfigured unless you have proven (say, with ntpq) that it
was initially working and failed to discipline the clock properly.

It's *very easy* to screw up the config, and I certainly did it a few
times. For example, you might have made the mistake I made when I
started: starting ntpd without making an ntpdate or ntpd -q call first.
If you start more than several minutes off, ntpd won't even try because
you've already exceeded its panic threshold.

Another good way to screw it up is to try to make it a little more secure
and end up forbidding your own ntp daemon from disciplining your own
clock! Been there too....

Basically, check your logs and use ps to see if the daemon is running,
and/or use ntpq -p to see if it has properly acquired your timeservers.
Assuming you get that far, watch the symbols on the far left of the ntpq
output over the course of an hour or so. It needs a while after startup
to watch your timeservers to decide which one to believe (and to learn the
network delays), but eventually it decides which it thinks are best and
worst and marks them as such and locks on to the most consistent servers.

Ah, right, here's another possibility: is your hardware clock set for
local time or zulu time? I *think* ntpd *always* wants to set it for
zulu, and if I'm right about that and your clock is set for local time
(say, because it makes MS-Windows happy) then ntpd is going to work really
hard to work your clock back to GMT. That seems more likely to cause a
50% rate error than a bad clock, and wouldn't be a bug in either but more
of a case of operator error.

I don't recall anybody mentioning this, but a source-based distro is a
uniquely bad distro to use the Brute Force and Ignorance approach with
ntpdate in a cronjob because it is uniquely vulnerable to the resulting
race condition. By doing there is the very real possibility that the
clock will be stepped backward. When this happens, there is a window in
which files created or modified can have a creation or modification date
*earlier* than that of a file which was in reality touched earlier. What
do you think 'make' is going to do in this case? Think about it.

Dustin


--
gentoo-user@gentoo.org mailing list
Re: how to keep time current, ntp doesn't work [ In reply to ]
excellent post! small comments (queries really) below

On Wed, 20 Oct 2004 19:49:59 -0700 (PDT)
Dustin <laurence@alice.caltech.edu> wrote:

> On Wed, 20 Oct 2004, Josh Close wrote:
>
> > Problem with that is, nptd goes out of sync by more than 12 hours within a day.
>
> Then it is not running, because (unless you change the value) it panics
> and quits when it is more than (hmm, from memory, check the docs) several
> minutes off.
>
> Granted, it is possible that ntpd is really failing, but I am pretty sure
> that what is happening is that it never got started in the first place.
> There are several ways this can happen. I'm not saying ntpd can't fail
> (your clock sounds astoundingly bad--50% error?!?--and might give ntpd
> more trouble), but the odds are it's a configuration issue. I suggest you
> assume it is misconfigured unless you have proven (say, with ntpq) that it
> was initially working and failed to discipline the clock properly.
>
> It's *very easy* to screw up the config, and I certainly did it a few
> times. For example, you might have made the mistake I made when I
> started: starting ntpd without making an ntpdate or ntpd -q call first.
> If you start more than several minutes off, ntpd won't even try because
> you've already exceeded its panic threshold.
>
> Another good way to screw it up is to try to make it a little more secure
> and end up forbidding your own ntp daemon from disciplining your own
> clock! Been there too....
>
> Basically, check your logs and use ps to see if the daemon is running,
> and/or use ntpq -p to see if it has properly acquired your timeservers.
> Assuming you get that far, watch the symbols on the far left of the ntpq
> output

where are these symbls found? is this the output of ntpq -p again?

>over the course of an hour or so. It needs a while after startup
> to watch your timeservers to decide which one to believe (and to learn the
> network delays), but eventually it decides which it thinks are best and
> worst and marks them as such and locks on to the most consistent servers.
>
> Ah, right, here's another possibility: is your hardware clock set for
> local time or zulu time? I *think* ntpd *always* wants to set it for
> zulu, and if I'm right about that and your clock is set for local time
> (say, because it makes MS-Windows happy) then ntpd is going to work really
> hard to work your clock back to GMT. That seems more likely to cause a
> 50% rate error than a bad clock, and wouldn't be a bug in either but more
> of a case of operator error.

I _thought_ ntpd disciplined the internal/unix/kernel clock, not the
hardware clock. If I am right then the kernel clock should be set to UTC
on boot no matter whether the hw clock is set to local or UTC. Of course
this assumes that /etc/localtime and /etc/rc.conf are set right.

of course if those things are wrong, and the clock is 12 hours wrong to
start with, its never gonna get fixed by ntpd.

>
> I don't recall anybody mentioning this, but a source-based distro is a
> uniquely bad distro to use the Brute Force and Ignorance approach with
> ntpdate in a cronjob because it is uniquely vulnerable to the resulting
> race condition. By doing there is the very real possibility that the
> clock will be stepped backward. When this happens, there is a window in
> which files created or modified can have a creation or modification date
> *earlier* than that of a file which was in reality touched earlier. What
> do you think 'make' is going to do in this case? Think about it.
>
> Dustin
>
>
> --
> gentoo-user@gentoo.org mailing list

--
Nick Rout <nick@rout.co.nz>


--
gentoo-user@gentoo.org mailing list
Re: how to keep time current, ntp doesn't work [ In reply to ]
On Wed, 20 Oct 2004 19:49:59 -0700 (PDT), Dustin
<laurence@alice.caltech.edu> wrote:
> Then it is not running, because (unless you change the value) it panics
> and quits when it is more than (hmm, from memory, check the docs) several
> minutes off.

It's running when I do a ps on it.

>
> Granted, it is possible that ntpd is really failing, but I am pretty sure
> that what is happening is that it never got started in the first place.
> There are several ways this can happen. I'm not saying ntpd can't fail
> (your clock sounds astoundingly bad--50% error?!?--and might give ntpd
> more trouble), but the odds are it's a configuration issue. I suggest you
> assume it is misconfigured unless you have proven (say, with ntpq) that it
> was initially working and failed to discipline the clock properly.

Could be misconfigured. The /etc/ntp.conf file has no comments in it,
so I'm not really sure what settings I need to change, but when it's
started, it stays running.

>
> It's *very easy* to screw up the config, and I certainly did it a few
> times. For example, you might have made the mistake I made when I
> started: starting ntpd without making an ntpdate or ntpd -q call first.
> If you start more than several minutes off, ntpd won't even try because
> you've already exceeded its panic threshold.
>
> Another good way to screw it up is to try to make it a little more secure
> and end up forbidding your own ntp daemon from disciplining your own
> clock! Been there too....

How can I tell if I've done this? Can you post some examples of configs?

>
> Dustin
>
>


-Josh

--
gentoo-user@gentoo.org mailing list
Re: how to keep time current, ntp doesn't work [ In reply to ]
I missed the start of this thread, but are you using a laptop? - this
was a widespread problem at one time caused by batterystat applets (and
sometimes kde apps) taking too long checking /proc, and basicly losing a
varying amount of cpu time - ntp without the panic argument cant track
the resulting jitters. Occaisionally happens to desktops.

BillK

On Thu, 2004-10-21 at 10:49, Dustin wrote:
> On Wed, 20 Oct 2004, Josh Close wrote:
>
> > Problem with that is, nptd goes out of sync by more than 12 hours within a day.



--
gentoo-user@gentoo.org mailing list
Re: how to keep time current, ntp doesn't work [ In reply to ]
why not tell us whats in your conf file?


On Wed, 20 Oct 2004 22:35:27 -0500
Josh Close <narshe@gmail.com> wrote:

> Could be misconfigured. The /etc/ntp.conf file has no comments in it,
> so I'm not really sure what settings I need to change, but when it's
> started, it stays running.

--
Nick Rout <nick@rout.co.nz>


--
gentoo-user@gentoo.org mailing list
Re: how to keep time current, ntp doesn't work [ In reply to ]
Casper the Friendly Ghost wrote:

> my advice would be to run ntp-client in a cron job (hourly is what you
> probably want)

If your using some public source, you do *NOT* want to setup an
hourly cron job, as it adds to much load to those systems!

With the *VERY* *VAST* majority of systems out there, the clock
runs good enough, so that a daily or weekly cron job run would
be what one wants.

Alexander Skwar
--
panic("aha1740.c"); /* Goodbye */
2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯


--
gentoo-user@gentoo.org mailing list
Re: how to keep time current, ntp doesn't work [ In reply to ]
* Josh Close <narshe@gmail.com> [2004-10-20 17:00]:
> How can I keep the date/time on my system current? Ntp
> hasn't been doing it's job. I read somewhere on the forums
> that ntp doesn't work when the system is under heavy load.
> I'm guessing that's what's happening here since the system
> runs at 99% cpu quite often.....

Try openntpd... It works for me. (the only caveat is when you
unplug your computer from network and reboot machine -
hangs on openntpd starting and trying to connect...)
I'd say it's much simpler to setup (Used to use ntpd too)

--
gentoo-user@gentoo.org mailing list
Re: how to keep time current, ntp doesn't work [ In reply to ]
On Thu, 21 Oct 2004 17:59:36 +1300, Nick Rout <nick@rout.co.nz> wrote:
> why not tell us whats in your conf file?
>
> Nick Rout <nick@rout.co.nz>

I'm using the default by gentoo install.

server pool.ntp.org
driftfile /var/lib/ntp/ntp.drift
restrict default notrust nomodify
restrict 127.0.0.1

-Josh

--
gentoo-user@gentoo.org mailing list
Re: how to keep time current, ntp doesn't work [ In reply to ]
On Thu, 21 Oct 2004, Nick Rout wrote:

> > Basically, check your logs and use ps to see if the daemon is running,
> > and/or use ntpq -p to see if it has properly acquired your timeservers.
> > Assuming you get that far, watch the symbols on the far left of the ntpq
> > output
>
> where are these symbls found? is this the output of ntpq -p again?

Yes.

laurence@poly:~$ /usr/sbin/ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
+foo.bar 0.0.0.0 1 u 5 64 377 11.828 -139.49
43.255
*baz.biff .GPS. 1 u 6 64 377 28.593 -199.43
48.570
+clock.schmoo .CDMA. 1 u 6 64 377 24.481 -125.29
60.806
+zorac.schwack XXX.XXX.XXX.XXX 2 u 1 64 377 11.912 -191.18
42.438
laurence@poly:~$

So far as I've been able to guess (and I admit too much laziness to track
down the truth right now), ntpd has accepted all four timeservers as
truechimers, i.e. any would provide a reasonable time signal. I believe
marked it's current first choice with a '*' and the other truechimers with
a '+'. Sometimes it decides one has gone insane (i.e. too erratic or too
different from the others) and marks it with an 'x', which I think means
it isn't being taken into consideration at the moment.

Other fun things: the first three servers are stratum 1, i.e. they are
synchronized with some hardware clock, not over the network. The second
server uses a GPS signal, while the "CDMA" for the third server is, I
believe, a cellular phone signal (while not as good as GPS or WWV,
apparently CDMA is fairly good because cell phones need good time signals
to work properly, for some reason I've never learned). The first one is
GPS as well; it's misconfigured as far as reporting its source, but I
happen to know what it is actually using. (I reported the error, but
apparently it was configured by the Navy and so the operators won't touch
the configuration.) The fourth server is stratum 2, sync'd to the stratum
1 server XXX.XXX.XXX.XXX.

(Yes, you in the back, I *am* sync'd to several stratum 1 servers in spite
of not having a large private network sync'd off of me. I have permission
for all of them, and I have joined pool.ntp.org to help distribute the
load. I encourage anyone with a stable working ntpd and some spare
bandwidth to consider doing the same. Check out www.pool.ntp.org.)

> > Ah, right, here's another possibility: is your hardware clock set for
> > local time or zulu time? I *think* ntpd *always* wants to set it for
> > zulu, and if I'm right about that and your clock is set for local time
> > (say, because it makes MS-Windows happy) then ntpd is going to work really
> > hard to work your clock back to GMT. That seems more likely to cause a
> > 50% rate error than a bad clock, and wouldn't be a bug in either but more
> > of a case of operator error.
>
> I _thought_ ntpd disciplined the internal/unix/kernel clock, not the
> hardware clock. If I am right then the kernel clock should be set to UTC
> on boot no matter whether the hw clock is set to local or UTC. Of course
> this assumes that /etc/localtime and /etc/rc.conf are set right.

I'm quite sure you're right about it using the kernel clock. I'm not sure
if your conclusion follows, though it makes sense, so I'll take your word
for it. Certainly nobody has mentioned having a problem if they installed
with "hardware clock keeps local time." But then, ntpd is not so much
designed for us little guys as big guys with serious timekeeping
constraints. Given that dual-booting with MS-Windows is the only reason
(I know of) to keep the hardware clock on local time, it may well be that
any problems are just below their radar screen.

The nice thing about open source is that we get to use a time service that
performs so well on our home machines. As long as I have ntpd the
computer is the most accurate clock in the house, probably even more
accurate than the watch I used to have that syncs with WWV (because it
probably drifted more between the daily synchronization than ntpd allows).

> of course if those things are wrong, and the clock is 12 hours wrong to
> start with, its never gonna get fixed by ntpd.

That should be right, I was just babbling without thinking.

Dustin


--
gentoo-user@gentoo.org mailing list
Re: how to keep time current, ntp doesn't work [ In reply to ]
On Wed, 20 Oct 2004, Josh Close wrote:

> > Another good way to screw it up is to try to make it a little more secure
> > and end up forbidding your own ntp daemon from disciplining your own
> > clock! Been there too....
>
> How can I tell if I've done this? Can you post some examples of configs?

I *believe* (as I keep saying, I'm no ntp expert, I just like having an
accurate clock well enough to have plugged away until I got it right) that
if it can't reach its servers but is configured well enough to run then
when you do ntpq -p it will say it's sync'd to 127.0.0.1, i.e. to itself.
Or, looking at my config file, that's maybe 127.127.1.0. Look for a line
like

server 127.127.1.0 # local clock

which tells NTPD that it's OK to use the local clock.

Again, this is vague memory from the docs, so by all means check them out:

http://www.eecis.udel.edu/~mills/ntp/html/index.html

The official docs are neither well organized nor newbie-friendly (again,
they're written for bigger fish with some technical background in the
problem being solved, very much in the spirit of unix and unix man
pages 8-O ), but there are some nicer-looking docs at

http://ntp.isc.org/bin/view/Support/WebHome

that I wish I'd found when I first configured the silly thing. Those are
links from www.ntp.org, so by all means poke around.

Config file: mmm, OK, confession time. Currently I'm running Slack, not
Gentoo. I should maybe post something about that since I joined the list
to get help with the problem that ultimately led to the Slackware install,
but that's another thing. Just as long as you know this is a Slackware
10.0 sample config file that I've tweaked, not the Gentoo sample config.
This config is a work in progress, so it will change. Extra annotations
not in the config file are in [[]].

-----------------------------------------------------------------------

# Sample /etc/ntp.conf: Configuration file for ntpd.
#
# Dustin 10/17/04:
# * Set up timeservers
# * Set up as stratum 2 server
# * Broke out messages to a separate logfile
# * Note there are no man pages, but the html documentation is in
# /usr/doc/ntp-4.2.0/
#
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. The
# default stratum is usually 3, but in this case we elect to use stratum
# 0. Since the server line does not have the prefer keyword, this driver
# is never used for synchronization, unless no other other
# synchronization source is available. In case the local host is
# controlled by some external source, such as an external oscillator or
# another protocol, the prefer keyword would cause the local host to
# disregard all other synchronization sources, unless the kernel
# modifications are in use and declare an unsynchronized condition.
#

# Dustin 10/17/04 -- configure like we were in Gentoo, as a stratum 2
# server and contribute to the pool
#server 127.127.1.0 # local clock
#fudge 127.127.1.0 stratum 10

[.[.I'm guessing the point of that fudge is that if it can reach your
timeservers it will ignore such a low stratum clock, but if not then
it will at least keep running. I should play with this and see if
I want those lines uncommented.]]

# XXX.XXX.XXX.XXX, foo.edu -- closest server, and stratum 1
# Permission on file in email somewhere
server foo.edu

# XXX.XXX.XXX.XXX, bar.net -- closest open, no notification server
# These claim to be stratum 1--are they really OK to sync to?
server bar.net
# XXX.XXX.XXX.XXX, baz.net -- sister server at XXXXXXXXXXX
server baz.net

# XXX.XXX.XXX.XXX, gronk.org -- closest stratum 2 server
# I got no answer to my request, but the list just asked for notification
server gronk.org

[.[.Notice that I'm using hostnames, not IPs in the server lines. That is
nice for me if they change the IP of their timeservers, but really I
should change it to IPs and avoid all those useless DNS lookups. Plus
that way it won't hang on boot waiting for name resolution if the network
is unreachable. :-)]]

# Dustin 10/17/04 -- Separate out log messages
logfile /var/log/ntpd.log


#
# Drift file. Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
#
driftfile /etc/ntp/drift
multicastclient # listen on default 224.0.1.1
broadcastdelay 0.008

#
# Keys file. If you want to diddle your server at run time, make a
# keys file (mode 600 for sure) and define the key number to be
# used for making requests.
# PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote
# systems might be able to reset your clock at will.
#
#keys /etc/ntp/keys
#trustedkey 65535
#requestkey 65535
#controlkey 65535

[.[.If you're not using authentication keys like that, you *cannot* use
"restrict notrust" no matter what docs you find on the web.]]

# Don't serve time or stats or trust anyone else by default (more secure)
#restrict default noquery notrust nomodify
# Trust ourselves. :-)
#restrict 127.0.0.1

[.[.That's the Slackware default config, just uncomment to use. It's
probably a good one if you're just a client, *EXCEPT* that "notrust"
is a nasty trap for the newbie. See below.]]

# Dustin 10/17/04 -- We're a pool.ntp.org server now, have to change
# these reasonable defaults and let the world sync to us

[.[.Urk!!! Looks like when I hurriedly copied stuff over from my old Gentoo
config I lost my default restrict lines for the rest of the world. Back
to the drawing board...I won't try to fix it here though because I'll have
to watch it after I change it to make sure it's working. But at the
*minimum* I need to turn on "nomodify" for the world!!! The line I'm
adding right now for testing is

restrict default nomodify

you can use more restrictions if you're not in the pool and allowing
the world to sync to you.]]

[.[."restrict" is probably the nastiest trap for the newbie, because the
meanings of the keywords just aren't obvious.]]

# Allow the chosen nameservers, but they can't modify my machine
# (but I can still sync to them)
restrict foo.edu nomodify
restrict bar.net nomodify
restrict baz.net nomodify
restrict gronk.org nomodify

[.[.IIRC what this is doing is saying that I'm just syncing to them as a
lower stratum server. If I didn't have nomodify turned on it would mean
I was trying to join them as a peer--you can have a bunch of peers of
the same stratum watching each other and trying to keep better time
collectively than any one is capable of separately. If I had a bunch of
servers of my own I'd do that, but obviously I can't do it with someone
else's timeservers. So "nomodify" seems to mean their servers can't
modify mine directly, not that my own ntpd can't modify my own clock.]]

# Now allow unrestricted connections from localhost, req'd I think
# so that the computer can update the clock
restrict 127.0.0.1

[.[.IIRC this one is very necessary. If you leave "nomodify" on for
localhost, then I seem to recall I found out the hard way that your own
ntpd can't change its own local clock. Kinda defeats the purpose....]]

-----------------------------------------------------------------------

OK, now the most annoying one: "notrust". I carefully read the docs I
found on the web, and nothing worked. The reason is that, following
common but very bad programming practice, the meaning of "notrust" was
recycled to a radically different meaning a few versions ago:

http://mailman.ntp.org/pipermail/questions/2004-July/004095.html

There are lots of docs on the web that talk about the old meaning, so
reading the docs can actually be worse than total ignorance. The new
meaning is that "notrust" says to ignore everyone not cryptographically
authenticated. I'm guessing you don't want that, especially not before
you even have a basic working configuration.

As an aside, it's just plain cruelty for Patrick to suggest using it in
the ntp.conf comments--anyone who needs it probably knows to add it, and
anyone who doesn't know what it means probably can't use it anyway. I
kinda recall the Gentoo default config file suggesting it too, if so
that's also bad. I imagine all these distros just haven't gotten up to
speed on the meaning change yet. Without a working Gentoo install,
though, I can't emerge the latest ntp and check to see what is in there,
so I'm not submitting the bug report myself.

Dustin, currently Slacking out of necessity but who will probably be
running Gentoo again in the future


--
gentoo-user@gentoo.org mailing list