This evening, I found my mythbackend system running at full CPU on all
cores. It was the leap second problem - again. According to dmesg on
this system, it got a leap second inserted just before 0000Z Aug 1:
[202139.171571] Clock: inserting leap second 23:59:60 UTC
This system is running ntp synchronized to a stratum 2 time server (at a
Has anyone else seen this today?
The prior workaround resolved the problem:
date -s "`date`"
I didn't have any problem tonight as I wasn't locked on to another server.
I just fixed my config and restarted -- I'll advice if it happens next time.
This is not (reasonably) possible since no leap second notification
has been in the authoritative ntp source packets.
My suggestion is to (a) make sure your ntp daemon is running
properly, and (b) check to see if your "authoritative" source is
itself broken. Note that I recommend no less than 4 sources
so that the broken ones are thrown out (as "false tickers"),
with each source being from independent agencies/locations.
(of course, ultimately, NIST is usually the root source in most
of the world).
I didn't have any issues tonight, but when the last leap second
occurred a month ago, both myself and another coworker running myth
both had CPU load problems with our systems. We only figured out what
happened when sharing stories, noticing the time correlation, and then
hearing of issues another (non-myth) coworker had at the same time.
I think that used to be more true than now with the abundance of GPS
devices out there. Any GPS device is a stratum one NTP clock
And while for (long standing reasons having to do with navigation) USNO is
the definitive source of the GPS satellites clock adjustments (being in space
and moving quickly means relativity matters), USNO and NIST do regular
comparisons, and will "adjust" as needed, although BIPM is charged with
providing the "definitive" UTC for the world (which is about averaging about
100 atomic clocks around the world). Also note that the GPS satellites
do not do leap seconds.
Of course, there is also the GLONASS and GALIEO sat sources, and
for obvious reasons the Russians do not use NIST/USNO or BIPM.
I had the same problem today as I had the last time a leap second got
inserted. On one of our Ubuntu 12.04 servers (the same one as last time)
the root filesystem reported "no space left" even though normally there
are only ~11% out of 50GB are used. I couldn't find the cause of this
and a reboot solved the issue. Luckily I was still able to ssh into it...
I had no such log entry, dmesg or otherwise. Checked several of my Linux servers.
Ben Franklin quote:
"Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety."
I've not done extensive searching, but I see nothing that says a leap
second was added yesterday. The last one I can find added was June
30th, and all my searching shows that leap seconds are only added at
the end of June or December.
Someone in the OP's reference chain has left the 'Insert a leap second
at the end of this month' function enabled.
Keith Pyle <kpyle*******> says:
Bogus leap second was inserted; may be a very clever denial-of-service
MythTV FAQ Q: "Cheap frontend/backend?" A: Revo, $200-300 @ Newegg
Q: "Record HD cable/satellite?" A: Hauppauge HD-PVR, $200 @ Newegg
Q: "Can't change Live TV channels w/multirec!" A: Hit NEXTCARD key
More answers *******/lists/mythtv/> >
I've seen some discussion that there was a "fake" leap second inserted by some NTP servers yesterday. There is some speculation that this was a DOS attack (links 1 & 2 below), but the third link below reports that some NTP servers are still advertising the 6/30 leap second. That post also shows a command to see if your NTP server is still advertising the leap second.