3

I am not sure what I have setup wrongly and I can not get a trustworthy ntp server up and running. Note that this is only an intranet ntp server.

The server is a slackware system and so the config file is based on the template that I found there:

interface ignore wildcard interface listen 127.0.0.1 interface listen eth0 interface listen eth1 server 3.gr.pool.ntp.org iburst server 1.europe.pool.ntp.org iburst server 0.europe.pool.ntp.org iburst server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 driftfile /etc/ntp/drift multicastclient 224.0.1.1 # listen on default 224.0.1.1 broadcastdelay 0.008 restrict default kod nomodify notrap noquery nopeer restrict 3.gr.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery restrict 1.europe.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery restrict 0.europe.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery restrict 192.168.18.0 mask 255.255.255.0 nomodify notrap restrict 127.0.0.1 logfile /var/log/ntp.log

for a dump of the conf with comments see: http://pastebin.com/TP0KyRV7

note that the 192.168.18.0 network is the local intranet, that this ntp server serves.

a snippet of the log from the last few months. I don't see any useful information.

30 Nov 15:41:12 ntpd[28591]: 194.177.210.54 interface 192.168.201.210 -> (none) 30 Nov 15:41:12 ntpd[28591]: Deleting interface #1 eth0, 192.168.18.10#123, interface stats: received=136483, sent=136483, dropped=0, active_time=7277307 secs 30 Nov 15:41:12 ntpd[28591]: Deleting interface #0 lo, 127.0.0.1#123, interface stats: received=0, sent=0, dropped=0, active_time=7277307 secs 30 Nov 15:41:12 ntpd[28591]: 127.127.1.0 interface 127.0.0.1 -> (none) 30 Nov 15:41:12 ntpd[28591]: peers refreshed 30 Nov 15:41:15 ntpd[28591]: ntpd exiting on signal 15 1 Dec 13:56:56 ntpd[1650]: Listen normally on 6 multicast 224.0.1.1 UDP 123 1 Dec 13:56:56 ntpd[1650]: Joined 224.0.1.1 socket to multicast group 224.0.1.1 5 Dec 22:51:42 ntpd[18694]: Listen normally on 6 multicast 224.0.1.1 UDP 123 5 Dec 22:51:42 ntpd[18694]: Joined 224.0.1.1 socket to multicast group 224.0.1.1 27 Feb 14:17:23 ntpd[18694]: Deleting interface #5 lo, ::1#123, interface stats: received=0, sent=0, dropped=0, active_time=7226742 secs 27 Feb 14:17:23 ntpd[18694]: Deleting interface #4 eth0, fe80::21a:92ff:fe3a:ac17#123, interface stats: received=0, sent=0, dropped=0, active_time=7226742 sec s 27 Feb 14:17:23 ntpd[18694]: Deleting interface #3 eth1, fe80::211:6bff:fe32:f77e#123, interface stats: received=0, sent=0, dropped=0, active_time=7226742 sec s 27 Feb 14:17:23 ntpd[18694]: Deleting interface #2 eth0, 192.168.18.10#123, interface stats: received=120122, sent=120122, dropped=0, active_time=7226742 secs 27 Feb 14:17:23 ntpd[18694]: Deleting interface #1 eth1, 192.168.201.210#123, interface stats: received=6261, sent=7292, dropped=0, active_time=7226742 secs 27 Feb 14:17:23 ntpd[18694]: 155.207.113.227 interface 192.168.201.210 -> (none) 27 Feb 14:17:23 ntpd[18694]: Deleting interface #0 lo, 127.0.0.1#123, interface stats: received=0, sent=0, dropped=0, active_time=7226742 secs 27 Feb 14:17:23 ntpd[18694]: 127.127.1.0 interface 127.0.0.1 -> (none) 27 Feb 14:17:23 ntpd[18694]: peers refreshed 27 Feb 14:17:27 ntpd[18694]: ntpd exiting on signal 15 27 Feb 17:32:45 ntpd[1642]: Listen normally on 6 multicast 224.0.1.1 UDP 123 27 Feb 17:32:45 ntpd[1642]: Joined 224.0.1.1 socket to multicast group 224.0.1.1 12 Mar 22:11:51 ntpd[9153]: Listen normally on 6 multicast 224.0.1.1 UDP 123 12 Mar 22:11:51 ntpd[9153]: Joined 224.0.1.1 socket to multicast group 224.0.1.1 12 Mar 22:11:51 ntpd[9153]: ntpd: time slew +0.000000 s 12 Mar 19:40:09 ntpd[9564]: Listen normally on 6 multicast 224.0.1.1 UDP 123 12 Mar 19:40:09 ntpd[9564]: Joined 224.0.1.1 socket to multicast group 224.0.1.1

yet every so often the ntp server will stop working. When I check it out again it has drifted 3 hours ahead. And I do not think these 3 hours are a random number. This may be related to the fact that I am on EET (or EEST) time.

BIOS time is set to local time (how can I check that from within linux?)

After I run ntpdate 3.gr.pool.ntp.org, I get the following:

root@halki:~# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== +postmortem.csd. 122.231.59.246 2 u 18 64 1 15.646 21.219 0.471 *ntp.jine.se 192.36.144.22 2 u 16 64 1 78.292 3.687 0.251 +static-ip-85-25 192.168.100.15 2 u 15 64 1 50.748 -2.676 1.071 LOCAL(0) .LOCL. 10 l 25 64 1 0.000 0.000 0.000

Is there something wrong with my ntp.conf ?

Perhaps with my system's time zone settings ?

I am not sure how to check those. I know I have selected "Europe/Athens" during installation a few years ago, but echoing timezone variable $TZ returns an empty string.

date seems correct at the moment , but I can't be certain it will stay that way.

root@halki:~# date Thu Mar 12 20:22:39 EET 2015

can someone procide a few pointers as to what could be wrong / what to check?

EDIT

in slackware linux, the configuration file for the hardware clock is in /etc/hardwareclock . This is set to "localtime" in my case. This file is checked during boot by /etc/rc.d/rc.S in order to set the clock to UTC or localtime.

There seems to be something wrong with the RTC though. 

root@halki:/etc# hwclock --show --debug hwclock from util-linux 2.21.2 hwclock: Open of /dev/rtc failed: No such file or directory No usable clock interface found. hwclock: Cannot access the Hardware Clock via any known method.

This doesn't seem normal. Perhaps something is missing in my kernel , but can someone verify?

Improve this question
6
  • Could you check uptime of ntp server? Then check whether incident occured after a possible reboot? It may because of hardware and system time synchronization before shutting down or during starting. Commented Mar 12, 2015 at 19:15
  • I think you can check hardware clock with hwclock - hwclock --show Commented Mar 12, 2015 at 19:18
  • @xin uptime is 15 days at this point. I had to do a manual restart at the time. usually this server gets a reboot every 80-150 days.I will perhaps try another manual reboot to see at what time it will come back up. Commented Mar 14, 2015 at 15:57
  • @taliezin Hi there, see my edit about hwclock please. Commented Mar 14, 2015 at 15:57
  • @nass RTC configuration is in Device Drivers > Real time clock section of kernel configuration. You need enable some interfaces here. Commented Mar 14, 2015 at 16:48

2 Answers 2

Reset to default
2

yet every so often the ntp server will stop working. When I check it out again it has drifted 3 hours ahead. And I do not think these 3 hours are a random number. This may be related to the fact that I am on EET (or EEST) time.

If that means a machine reboots and then time messed up, It may be because of your OS, wrongly, thinks hardware clock indicates time as UTC. Then It adds 3hour to time that responded by hardware.

So, If problem happens after a reboot, tell the OS that hardware stores time as local time (which by your date output is in timezone EET):

# hwclock --localtime

Then adjust system time by date -d, till you get correct time. In the end, save that time into hardware clock:

# hwclock --systohc

BIOS time is set to local time (how can I check that from within linux?)

hwclock says what date is stored here but it won't tell you It's correct to see it as UTC or local time; It expect you inform him about this.

I am not sure how to check those. I know I have selected "Europe/Athens" during installation a few years ago, but echoing timezone variable $TZ returns an empty string.

Your timezone is printed by date. Check /etc/timezone which may contain name of timezone, e.g. Europe/Athens or /etc/localtime which may contain (or linked to a file containing) zoneinfo data; like files reside in /usr/share/zoneinfo.

Improve this answer
3
  • I checked and the /etc/localtime file is a binary file, not a link. so I am not sure. Do check my edit above though. Commented Mar 14, 2015 at 16:01
  • @nass that binary data is zone information Commented Mar 14, 2015 at 16:44
  • yes but which zone? i'll try to check with md5sum Commented Mar 14, 2015 at 18:42
1

There should be a configuration file under /etc which indicates whether the hardware clock is set to UTC or local time. This flag should be used on reboot to adjust the system time if appropriate. On Ubuntu the file is /etc/default/rcS.

There should also be a place you can add flags to the ntpd command when it starts. Add -g to the flags, and ntpd will stop panicking on reboot. By default it will refuse to startup if the clock is off by over 1000 seconds. It appears you are off by several times this so ntpd panics as designed. The -g option will prevent the startup panic.

Improve this answer
2
  • -g is there already. I used the term panic to denote it did not start up, because this is the term I found most often on google when searching for ntpd problems. see my edit for the conf file under /etc. Commented Mar 14, 2015 at 15:49
  • @nass If you are using NTP with the hardware clock you need to set the hardware clock to UTC. If you loose network connectivity, ntp may sync to the local clock, but it never sets it. /dev/rtc is the interface to one type of real time clock, but many motherboards use a different clock inteface. Commented Mar 14, 2015 at 16:23

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.