See this article.
Should these be temporarily removed from the NTP Pool?
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 ![]()
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.