Apparently the issues might be due "to the leapsecond being added without calling clock_was_set() to notify the hrtimer subsystem of the change", a possible fix being to patch kernel/time/timekeeping.c to be leapsecond aware.
That's predominantly about the kernel crash, not the high-CPU futex issue. One of the most maddening things about this is that there have been several different issues related to leap seconds on Linux, making it all the harder to get information.
Thank you for that link! I had been scratching my head about that server even though it wasn't mine to take care of (the other service I'm involved with here, that I helped plan, uses Postgres, which does not seem to have problems).
DST doesn't exist in UTC, so that's irrelevant. A one-hour UTC shift would totally, utterly, screw stuff up. But, at the current rate, a one-hour "leap" would happen in thousands of years, so maybe it's not such a bad idea after all. But I think the reason for leap seconds has to do with keeping UTC in sync with other clock systems, and that probably overrides any inconvenience to software.
The solution is not to change UTC, but just to rotate the time zones of each country every now and then. DST has proven that a country is able to change time zones twice a year. This would happen far less often.
Yes, it would be similar to Y2K. Hopefully politicians could agree decades in advance so people would have plenty of time to prepare. Also, since you're only changing the tzdata and not UTC, much less would break and most of the breakage would be purely cosmetic. Right now we have several tzdata changes per year and they cause much less disruption than leap seconds.
I can't switch to TAI because then I'd be 30 seconds off from everybody else. And everybody can't switch to TAI because that disruption would be even larger than what we saw this weekend. IMO the solution is to leave the leap seconds that were already added but not add any more.