Expired leapsecond file

[ZoltanHegedus]

By the /var/log/ntpd.err and ntpd.log

leapsecond file ('/var/db/ntpd.leap-seconds.list'): expired less than 325 days ago
unable to bind to wildcard address 0.0.0.0 - another process may be running - EXITING

17 Nov 16:00:00 ntpd[1313]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): good hash signature
17 Nov 16:00:00 ntpd[1313]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): loaded, expire=2017-12-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
17 Nov 16:00:00 ntpd[1313]: Listen and drop on 0 v6wildcard [::]:123
17 Nov 16:00:00 ntpd[1313]: Listen and drop on 1 v4wildcard 0.0.0.0:123
17 Nov 16:00:00 ntpd[1313]: Listen normally on 2 re0 [fe80::3265:ecff:fea5:5267%1]:123
17 Nov 16:00:00 ntpd[1313]: Listen normally on 3 lo0 [::1]:123
17 Nov 16:00:00 ntpd[1313]: Listen normally on 4 lo0 [fe80::1%2]:123
17 Nov 16:00:00 ntpd[1313]: Listen normally on 5 lo0 127.0.0.1:123
17 Nov 16:00:00 ntpd[1313]: Listening on routing socket on fd #26 for interface updates
17 Nov 16:00:00 ntpd[1313]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized

/var/log/messages

Nov 17 15:59:59 kernel: atrtc0: port 0x70-0x77 irq 8 on acpi0
Nov 17 15:59:59 kernel: atrtc0: Warning: Couldn't map I/O.
Nov 17 15:59:59 kernel: atrtc0: registered as a time-of-day clock, resolution 1.000000s

and the /var/log/messages is missing

[ZoltanHegedus]

Update: the /var/log/dmesg is missing not the /var/log/messages :-)

[ZoltanHegedus]

This error is in Trident pre-release yet:

26 Nov 10:28:48 ntpd[1611]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): good hash signature
26 Nov 10:28:48 ntpd[1611]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): loaded, expire=2017-12-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
26 Nov 10:28:48 ntpd[1611]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized

But I can sync the network time manually in terminal:

ntpdate pool 0.freebsd.pool.ntp.org

[RodMyers]

looks like this is a FreeBSD issue

[ZoltanHegedus]

Thanks for the information Rod!

[beanpole135]

Just for information: I think that is just a cosmetic warning during bootup because ntp is trying to check/update the time before the network is fully up and running. The "ntpd" service does periodic checks/upadates to the system time (including the leapsecond file) and automatically starts working as soon as your system is connected to the local network.

[ghost]

So, some background. There is an international organization that tracks the rotation of the earth - www.iers.org. They have the authority to issue an update to their Bulletin C, which determines whether a leapsecond is necessary. Doing so, influences Universal Coordinated Time (UTC) which is tracked by many international organizations and labs (NIST, USNO, etc.). Network Time Protocol software coordinates time for cooperating centers all over the world as well as on your system. The normal releases for Bulletin C (and the updated leapsecond file) are twice a year, at least 30 days prior to the end of December, and 30 days prior to the end of June. If no bulletin is issued, there is no need to add a leapsecond and the current file is the latest artifact in the list of updated leapsecond files.

The notation that the file is expired, points to a difference in point of view of how the file should be used. The IERS notation says that the file is valid at a point in time, until further notice. The IETF, in their version of the leapsecond file, state:

...  If an announcement by the IERS specifies that no leap second is scheduled then only
the expiration date of the file (the leapsecond file, Ed.), will be advanced to show that the
information in the file is still current -- the updated timestamp, the data and the name of the
file will not change.

So, in summary as Ken mentioned, it's a cosmetic notation, and not a system critical error.

[maxsteciuk]

Just for information: I think that is just a cosmetic warning during bootup because ntp is trying to check/update the time before the network is fully up and running. The "ntpd" service does periodic checks/upadates to the system time (including the leapsecond file) and automatically starts working as soon as your system is connected to the local network.

Regarding the order of ntpd and network services startup could it explain that time was out-of-sync when Trident full booted (up to Lumina)?

I had to explicitly invoke ntpdate to fix it

ntpdate 0.freebsd.pool.ntp.org
14 Dec 20:06:26 ntpdate[53415]: adjust time server 216.6.2.70 offset 0.000844 sec

[ZoltanHegedus]

I experienced yet, that the system clock is stopping under the system install procedure, but I think this is a different problem and maybe not important, because I can edit it. This means that after the first reboot the system time (the machine clock) is different from the right time with how long was the install procedure.
For example: for my machine the install time of theTrident about 10 minutes, if I reboot firstly than the system clock is in 10 minutes late.
Of course for the ntpdate 0.freebsd.pool.ntp.org command the system can update the time.

[beanpole135]

Yes, the default time set by the installer is just supposed to get "close" to the real time and setup your timezone properly, so that NTP can sync it up after that. Due to the lag in the actual time to perform the installation and the way the time gets passed to the installer backend, there is no easy way to fix that time lag in the initial setup procedure.

I am going to go ahead and close this (non-)issue. Might be interesting to see if the TrueOS devs are working on a fix for the network sync-on-boot issues.