Some NTP servers are advertising an upcoming leap second (leap=1)

See this article.

Should these be temporarily removed from the NTP Pool?

Some clients like timesyncd accept leap seconds on any day, so this definitely has some impact.

My monitoring data confirms that it all seems to be coming from LeoNTP servers (both the older and newer models) and it’s forwarded by few openntpd and routeros stratum>=2 servers, which don’t check the date either.

How to check the status with chrony:

chronyc tracking|grep Leap
Leap status     : Normal
chronyc selectdata -v
S Name/IP Address        Auth COpts EOpts Last Score     Interval  Leap
=======================================================================
+ leontp1.xxx.nl            N ----- -----  103   1.0 -2695us +1896us  +
* yyy.nl                    N ----- -----  161   1.0 -1617us  +983us  N
+ zzz.nl                    N ----- -----    0   1.0 -1997us +1532us  N
+ qqqq                      N ----- -----  413   1.2 -1581us +1067us  N

A + in the leap field means the source is announcing an upcoming leap second.

I’ll add something to filter these (I was reluctant before because I was worried I’d screw it up in some way that’d take the pool offline when there was a real leap second, but thankfully we’re very close to done with those!)

In the 2021 incident 136 pool servers did this, today it’s just 27 (so at least there’s that). In 2021 the servers were different across a few days, so putting this in place now might help over the next couple days.

And … 8 of the servers are the same as 5 years ago.

I have one of these.

Is there anything I can do to check and mitigate the error?

I don’t have these devices, but the status screen might show if it thinks there’s a leap second coming up:

Besides that, upgrading your device’s firmware to the latest version would probably be a good idea.

I bought it fairly recently and it’s not showing an upcoming leap second so I think it should be OK :wink:

For anyone wondering whether their own server is exposed: a client that polls several independent sources is much safer than one pointing at a single upstream. chrony only acts on a leap second announcement when a majority of its selected sources agree, so one misbehaving server announcing leap=1 gets outvoted. You can see what each source claims with chronyc selectdata (the Leap column), and your own state with chronyc tracking | grep Leap, which should say Normal. With ntpd, ntpq -c rv shows the leap field of your server; leap=00 is normal and leap=01 means an insertion is being announced. The practical takeaway is to use at least four diverse sources, and avoid single-server setups such as a default systemd-timesyncd, which has no majority vote.

There are two LeoNTP models. Both have corrected firmware available.
the LeoNTP and LeoNTP 1200. The LeoNTP 1200 has an automatic firmware update feature.
I have both models using the current firmware; neither one showed a leap second.

I watched the NTP Pool servers at the time of the ā€œleap secondā€ None of them showed an off-by-one-second error. [I could have missed a short-lived time error.]

The management of the leap second status has been problematic, though I don’t have all of the history. Can a leap second occur on days other than the last day of a month? How should a client determine that a leap second will occur: From single server? From a majority of servers? Can servers undo the leap second signal? I don’t want to debate this topic, because I think the semantics are settled by now. The point is that this has been confusing.

If history repeats, there will be a largely-different set of NTP servers that will signal and execute the leap second at the end of the month. If these could be identified and re-initialized the erroneous leap second status would be cleared, I think. Very few NTP servers allow remote status query, however.

Just type in ssh: ā€˜ntpdate ipaddress’

At the end of the line it should say: no-leap

As of 2026-10-31 00:40 some NTP servers are advertising leap=1. The (currently 9) NTP pool servers were not seen on October 24. Past experience suggests that the number will increase, especially in the hour before midnight UTC.

Sorry to keep bringing up this topic.

It seems at least 7 server IP addresses actually leaped at the midnight. Great that the monitoring system removed them from the pool, at least for the majority of simple clients that use DNS before each NTP request.