![](https://seccdn.libravatar.org/avatar/5e70f769092f3372f14b4f2df58a17e1.jpg?s=120&d=mm&r=g)
On 31/10/06 00:25, Hylton Conacher(ZR1HPC) wrote:
... time between the ntp checks? The last check was at 07h29 and the time now is 08h24 and it hasn't checked inbetween.
I have tried to look at 'man ntp' but was pointed onto '/usr/share/doc/packages/xntp-doc' which doesn't exist on my system, I do however have a '/usr/share/packages/xntp/' folder. Entering this folder also did not provide me with the required 'xntp-doc' file. I figured no problem and searched Yast for both ntp and xntp-doc with both NOT returning the ntp-doc package I am looking for. /usr/share/doc/packages/xntp-doc/* in the xntp-doc package.
The out-of-the-box ntp config file *should* by default log all the
information I mention here. If not, you'll need to edit the "logconfig"
line in the ntp.conf file (see below), restart the daemon, and wait for
sufficient data to be logged to be of any help.
If you are only seeing lines in the ntp log file looking like this:
30 Oct 11:37:38 ntpd[6775]: offset 0.000365 sec freq 80.810 ppm error
0.003527
then you are only seeing the hourly log of the current clock stats. This
information is logged irrespective of the actual poll events to the
servers.
Any lines indicating a problem reaching a particular server will look
like this:
22 Oct 09:02:20 ntpd[6775]: peer 128.233.154.245 event 'event_unreach'
(0x83) status 'unreach, conf, 2 events, event_unreach' (0x8023)
The next time a valid poll does come in from the same server, you'll get
this:
22 Oct 18:00:49 ntpd[6775]: peer 128.233.154.245 event 'event_reach'
(0x84) status 'unreach, conf, 3 events, event_reach' (0x8034)
Every time the daemon synchronizes to a different server, you get a line
like this:
22 Oct 18:27:55 ntpd[6775]: synchronized to 128.233.154.245, stratum 1
If your system has an uptime of a few days or more, check for the most
recent "synchronized to" line in the ntp log; that's probably the
quickest way to tell if you're having a general problem polling your
servers. You can also grep the ntp log for "event_unreach"; a lot of
those really indicates a major problem.
To get an idea of what is happening, as root, enter "ntpdc" at a command
prompt to get to the ntpd console, then enter "peers" (without quotes)
to get a listing of the current status. You'll see something like this:
remote refid st t when poll reach delay offset
jitter
==============================================================================
LOCAL(0) LOCAL(0) 10 l 53 64 377 0.000 0.000
0.004
+sue.cc.uregina. 164.67.62.194 2 u 134 512 377 34.730 -9.169
23.238
-time4.cpsc.ucal 10.10.0.22 2 u 144 512 377 33.474 -6.741
1.068
*tick.usask.ca .GPS. 1 u 568 512 376 68.157 -0.509
0.411
-nss.nts.umn.edu 160.94.54.248 2 u 103 512 377 60.246 6.912
5.824
+br1.umtnet.umt. 204.123.2.5 2 u 27 512 377 62.520 -0.316
29.070
This says I am synchronized to tick.usask.ca, which is running at
stratum 1, which was last successfully polled 568 seconds ago (with a
maxpoll 9, it's somewhat overdue.. a successful poll actually occurred
about 200 seconds later). The "poll" column indicates the current poll
interval (which xntpd will adjust depending on how reliably a server can
be reached), while the "reach" column gives a rough indication of the
overall reliability of that server. Here, tick.usask.ca has a slightly
reduced reliability, on account of the minor problem in reaching it.
If you really are having problems with your server(s), then you'll need
to edit the config file, /etc/ntp.conf. For the most part, you'll have
to edit it manually, as Yast can only do very basic configuration of the
server directives, and then only if you already know the options and how
to use them. The basic server directive looks like this:
server