For some reason, it appears that the /etc/ntp.conf file is getting ignored by the NTP service on Raspberry Pi images. When you start the service either from the UI or by using 'service ntp start' on the command line, the following appears (domains changed to protect the guilty). I have left the system running in this state for over a week with no change:
wolfstar@rsquared:~$ service ntp status
NTP server is running.
wolfstar@rsquared:~$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
rsquared.example .INIT. 16 u - 64 0 0.000 0.000 0.000
wolfstar@rsquared:~$
As you can see, 'rsquared' is the hostname of the RPi itself. (Pi 2 if it matters.) Below is my /etc/ntp.conf; it is using an internal ntp server as I was trying to rule out issues with NAT or firewalling.
wolfstar@rsquared:~$ cat /etc/ntp.conf
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
driftfile /var/lib/ntp/ntp.drift
# Disable the panic feature.
tinker panic 0
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
#server 127.127.1.0 # Local clock
#fudge 127.127.1.0 stratum 12
server moonhawk.example.org iburst
# By default, exchange time with everybody, but do not allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1
wolfstar@rsquared:~$
Alles anzeigen
If I stop the service, then manually run ntpd, I get an immediately different result:
wolfstar@rsquared:~$ sudo service ntp stop
Stopping NTP server: ntpd.
wolfstar@rsquared:~$ sudo service ntp status
NTP server is not running ... failed!
wolfstar@rsquared:~$ sudo ntpd
wolfstar@rsquared:~$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*moonhawk.example 64.71.128.26 3 u 6 64 1 0.249 -2.957 0.038
wolfstar@rsquared:~$
If I were to kill the NTP server and restart the service, it would go back to trying to connect to itself. This appears to be ONLY an issue with the Raspberry Pi images, because the time server that the Pi is connecting to above is also an OMV machine running on a Xeon-based system. If I rename /etc/ntp.conf (in this case to /etc/orig.ntp), the output of 'ntpq -p' is 'No association ID's returned', so clearly the Pi is reading some alternate ntp.conf from somewhere, but it's not the one in /etc/ when the service starts up.
I suspect this is what's caused the date/time posts that crop up from time to time; they always appear to be Raspberry Pis that have the issue. Any help tracking down what's causing this is greatly appreciated.