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 <server_name> [possible other stuff] maxpoll <integer> You should have a minimum of 3 servers in use, and these shouldn't be local to each other. If you need to find a server or two, you'll find plenty at http://ntp.isc.org/bin/view/Servers/WebHome (paragraph "Finding a Time Server"). Without the maxpoll option, <integer> defaults to 10, which is a power of 2, giving a maxpoll interval of 1024 seconds. With the maxpoll option, this can be set as high as 17, which is just over 36 hours. If your poll interval is controlled by a maxpoll directive, check for "maxpoll 12" or greater, which gives a maximum interval of 4096 seconds or more. Use a maxpoll value of 8 or 9 to see if things improve. (There is also a minpoll, which defaults to 6, or 64 sec, but can be set as low as 4, 16 seconds.) If you aren't getting the information I mentioned in your logfile, then you'll need to modify the "logconfig" directive, just change it to "logconfig =all" (without the quotes, with the space, and with the equals sign), and restart the daemon.