Solved ntpd not syncing on startup

Currently running : 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC arm64 on a Raspberry Pi 3+. I'm only a few steps in from the base image. At this point I'm configuring ntpd because the RPi doesn't have a RTC and I need it to have accurate time.

Ran pkg install ntpd and the installation completed successfully. Added the following lines to /etc/ntp.conf:
Code:
server 0.north-america.pool.ntp.org iburst
server 1.north-america.pool.ntp.org iburst
server 2.north-america.pool.ntp.org iburst
server 3.north-america.pool.ntp.org iburst

#restricted because I only want this machine to check time and correct the clock, not serve time
restrict default ignore

Added the following lines to /etc/rc.conf as per the ntpd documentation:

Code:
ntpd_program="/usr/local/sbin/ntpd"
ntpdate_program="/usr/local/sbin/ntpdate"
ntpd_enable="YES"
ntpd_sync_on_start="YES"

The documentation states that if the system clock is off by more than 1000s when ntpd starts the daemon will fail. Adding ntpd_sync_on_start="YES" to rc.conf runs the daemon once with -g which forces a sync no matter the time difference.

In my case ntpd is not correcting the system clock on reboot. Running date shows the system clock to be off by about 10 minutes After a couple hours uptime the clock is off by the same amount. No apparent errors in /var/log/messages, only the following:
Code:
Dec 30 02:20:14 BSDTor kernel: Security policy loaded: MAC/ntpd (mac_ntpd)
Dec 30 02:20:15 BSDTor ntpd[954]: ntpd 4.2.8p12@1.3728-o Tue Dec 18 20:41:39 UTC 2018 (1): Starting
Dec 30 02:20:15 BSDTor ntpd[955]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): good hash signature
Dec 30 02:20:15 BSDTor ntpd[955]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): loaded, expire=2017-12-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
Dec 30 02:20:15 BSDTor ntpd[955]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): expired less than 368 days ago

I can manually run ntpdate -u pool.ntp.org or stop ntpd and run ntpd -gq manually then restart ntpd but this only works for the current session. If the server gets rebooted how can I be sure it will sync the time, since ntpd_syc_on_start doesn't seem to be working, and how can I make ntpd_syc_on_start work as advertised?
 
Regarding the leap-seconds file run service ntpd fetch to retrieve a current version. I have no idea about the other problems.
 
Currently running : 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC arm64 on a Raspberry Pi 3+. I'm only a few steps in from the base image. At this point I'm configuring ntpd because the RPi doesn't have a RTC and I need it to have accurate time.

Ran pkg install ntpd and the installation completed successfully.
Note that ntpd is already part of the base system. I advise you to remove the package because it complicates things – for example, when you run ntpd on the command line, it depends on your PATH setting which of the two ntpd versions is actually called.
Added the following lines to /etc/ntp.conf:
Code:
server 0.north-america.pool.ntp.org iburst
server 1.north-america.pool.ntp.org iburst
server 2.north-america.pool.ntp.org iburst
server 3.north-america.pool.ntp.org iburst

#restricted because I only want this machine to check time and correct the clock, not serve time
restrict default ignore
That won't work, unless you also add appropriate restrict lines for the four server entries. That's because the line restrict default ignore ignores all packets by default, including replies to time queries. In other words: You never receive an answer from the time servers.

Another thing to consider is whether your network is actually up at the point ntpd is started during the boot sequence. The NTP protocol is designed to work over unreliable networks, so it is based on UDP, which means that lost packets are not retransmitted automatically. To ensure that the network is up, I recommend using the netwait feature; please see the netwait_* entries in the rc.conf(5) manual page.

PS: You can use the command ntpq -p to find out if any of your NTP servers are actually reachable and answer to time queries. The output also indicates against which of your servers you are currecntly synchronized, if any.
 
What does ntpq -c peer return whhen the time is not synch'ed?

Code:
    remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 thelinuxman.us  .INIT.          16 u    -   64    0    0.000    0.000   0.000
 ntp.wdc1.us.lea .INIT.          16 u    -   64    0    0.000    0.000   0.000
 clocka.ntpjs.or .INIT.          16 u    -   64    0    0.000    0.000   0.000
 clockb.ntpjs.or .INIT.          16 u    -   64    0    0.000    0.000   0.000

So obviously not receiving replies from any server

Note that ntpd is already part of the base system. I advise you to remove the package because it complicates things – for example, when you run ntpd on the command line, it depends on your PATH setting which of the two ntpd versions is actually called.

Well now, I didn't realize that. This BSD NOOB finds it odd pkg would happily install something that is already installed. Anyway, I ran pkg remove ntp and rebooted.

That won't work, unless you also add appropriate restrict lines for the four server entries. That's because the line restrict default ignore ignores all packets by default, including replies to time queries. In other words: You never receive an answer from the time servers.

This might have been the lynchpin. I added the following to /etc/ntp.conf and restarted ntpd with service ntpd restart
Code:
restrict 0.north-america.pool.ntp.org 
restrict 1.north-america.pool.ntp.org
restrict 2.north-america.pool.ntp.org
restrict 3.north-america.pool.ntp.org

Now all four servers show numbers in the reach, delay, offset and jitter columns. After just a minute or two I ran date and the system clock is now set correctly.

Another thing to consider is whether your network is actually up at the point ntpd is started during the boot sequence. The NTP protocol is designed to work over unreliable networks, so it is based on UDP, which means that lost packets are not retransmitted automatically. To ensure that the network is up, I recommend using the netwait feature; please see the netwait_* entries in the rc.conf(5) manual page.

It seems to be working as-is without adding the netwait feature. Perhaps the base install does this automatically? Regardless, adding the four restrict lines for each time server and removing the confusing ntpd package fixed the issue.
 
This BSD NOOB finds it odd pkg would happily install something that is already installed.
They're not exactly the same, ntpd(8) is not a package, it's part of the base OS. net/ntp can be installed next to it because all ports use /usr/local/ as a prefix. While both are named the same and have the same purpose they are not the same implementation.
 
Currently running : 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC arm64 on a Raspberry Pi 3+. I'm only a few steps in from the base image. At this point I'm configuring ntpd because the RPi doesn't have a RTC and I need it to have accurate time. ....

I work mainly with BeagleBone Blacks but the problem is the same. The machine does not have a battery to keep the time up to date.

Since my embedded usually are set to reboot once per day, I solve the time problem with this cron line.
Code:
@reboot /usr/sbin/ntpdate it.pool.ntp.org

bye
Nicola
 
Just set ntpdate_enable="YES" in rc.conf. That will automatically sync the time at boot.
 
They're not exactly the same, ntpd(8) is not a package, it's part of the base OS. net/ntp can be installed next to it because all ports use /usr/local/ as a prefix. While both are named the same and have the same purpose they are not the same implementation.
So the question arises "Why even have net/ntpd as a port when ntpd is included in the base?
 
To have a choice? Besides being a different implementation, the port also allows you to enable/disable a whole slew of options. With most of them not supported or enabled on FreeBSD's own ntpd(8).
 
This BSD NOOB finds it odd pkg would happily install something that is already installed.
Well, FreeBSD is somewhat different from most Linux distributions in this regard. FreeBSD's so-called base system itself does not consist of packages (although there is work underway to change this). There are quite a few pieces of software that are included in the bases system and that are available as a package (or can be built from the Ports Collection). These include ntpd, openssh, the compiler suite (llvm / clang) and several other things. You can install them at the same time without conflict: The base system stuff is located in /usr/bin, /usr/lib and so on, while the additional packages are installed under /usr/local. You just have to be careful not to confuse them if you have both installed.

The reason for having those pieces of software in the base system is that they're deemed important enough that many (or even most) users will benefit from them being available out of the box, without having to download additional software. For example, almost everybody will need ssh. There are also some cases where a piece of software is kept for historical reasons or “BSD tradition”. For example, sendmail has been part of BSD UNIX for almost 40 years.

Such software is usually also available from the Ports Collection (and as binary packages). The reason for that is that the versions included in the base system are often stripped down and somewhat limited. For example, the version of ntpd included in the base system is perfectly fine to be used as a client or simple server. However, the version of ntpd in the Ports Collection includes wider support for various kinds of hardware reference clocks, and it supports SNMP and a few other things that most people won't need. Also, software in the Ports Collection is easier to update, so it is often a newer version than the one in the base system.
 
olli@ said:
There are also some cases where a piece of software is kept for historical reasons or “BSD tradition”. For example, sendmail has been part of BSD UNIX for almost 40 years.
BIND in BSD is a tradition worth keeping.

Nothing says that this box is "core infrastructure" than BIND on BSD. Historically speaking, of course.
 
Back
Top