Raspberry Pi: NTP service not using /etc/ntp.conf

  • 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:


    Code
    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.



    If I stop the service, then manually run ntpd, I get an immediately different result:


    Code
    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.

    • Offizieller Beitrag

    You need a realtime clock. Read

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Well, it looks like this had actually nothing to do with needing an RTC, in this case. I was able to get it solved while working up this post and collecting information, but I'll leave the info here for people who search on it.


    I'm still getting the RTC working, but I was also seeing the exact same behavior on my dual-Xeon E5620 Intel server that's my primary OMV box. I have an older server that I moved to virtual a while back, and it worked fine. When I ran ps to see what the commands are, this is what I see. Note: njall is the P2V image that works, moonhawk is the dual-Xeon, and rsquared is the Pi.



    Code
    root@rsquared:~# ps aux | grep ntp
    ntp       2810  0.0  0.3   5380  3728 ?        Ss   20:51   0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /var/lib/ntp/ntp.conf.dhcp -u 102:104
    root     15337  0.0  0.1   3536  1828 pts/0    S+   21:08   0:00 grep ntp
    root@rsquared:~# ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
     rsquared.shadow .INIT.          16 u    -  512    0    0.000    0.000   0.000
    root@rsquared:~#


    Code
    root@moonhawk:~# ps aux | grep ntp
    root     26885  0.0  0.0   7848  2004 pts/1    S+   21:09   0:00 grep ntp
    ntp      27410  0.0  0.0  34884  4396 ?        Ss   20:32   0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /var/lib/ntp/ntp.conf.dhcp -u 101:104
    root@moonhawk:~# ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
     rsquared.shadow .INIT.          16 u    8  128    0    0.000    0.000   0.000
    root@moonhawk:~#



    Note that host rsquared, the Raspberry Pi, is serving as DHCP server for the entire network. All three servers are configured with static IPs. That extra '-c /var/lib/ntp/ntp.conf.dhcp' is the culprit here; apparently at one point or another I had both moonhawk and the RPi configured as DHCP - in moonhawk's case accidentally while setting up a bridge interface for something else. That file gets created it there's an NTP server configured on the DHCP server (in this case, there is and always has been), and even if you later configure it for static, that file doesn't get removed. In this case, the RPi replaced the virtual server, and for simplicity I used the same IP address as a couple of other devices referred to it.


    So if your NTP daemon appears to be completely ignoring /etc/ntp.conf, run 'ps aux | grep ntp'. If you see '-c /var/lib/ntp/ntp.conf.dhcp' as part of the command it's running, delete that file and it will revert to /etc/ntp.conf. Please note that if you are using DHCP on your OMV machine, it will go BACK to using that file the next time you get a DHCP lease and your OMV box reboots.


    Now, I'm gonna go get that RTC chip working. :)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!