Slashdot Mirror
NTP Glitch Reverts Clocks Back To 2000
An anonymous reader writes "It seems a glitch of some sort wreaked havoc on some NTP servers yesterday, causing many machines to revert to the year 2000. It seems the Y2K bug that never happened is finally catching up with us in 2012."
And end-user systems certainly don't accept that large a skew. ntpd on end-user systems would just have been unable to sync their time while the servers were affected.
NTP -- at least, the formal Unix client -- already has checks in place to reject huge clock skews like this.
The failure, of course, was dipshit Windows clients talking directly to low-strata servers. And then blindly accepting such a massive skew. Good jorb there, Microsoft, as always.
Generally xntpd and its ilk will not step the time more than a small amount, but will rather give up and quit instead. One machine such as (say) the RPi with no RTC that use ntpdate to *set* rather than *adjust* the clock, this is harder to avoid, but servers should not be automatically running ntpdate when configured properly.
So there may be *two* bugs here to get the problem: one in an NTP implementation and one in use of ntpdate for anything other than manual updates on servers. But I haven't read TFA yet.
(On the little bit of work I put into the ARCRON driver I inserted extra code to look out for year rolls, etc, on top of whatever xntpd would do. In part because ARCRON only sends 2-year dates IIRC.)
Rgds
Damon
http://m.earth.org.uk/
Why do people keep pretending that it wasn't? It was a real issue, that required real work to fix. If none of that work had happened, it would've hit and it would've hit hard.
Lots of organizations worked hard to prepare for Y2K. Lots of other organizations did absolutely nothing to prepare. Neither had any significant problems on 1/1/2000. The reason is there were very few problems to begin with. The myth was that back when memory was precious, programmers stored the year in two bytes instead of four. But those of us that actually programmed in the days when 4K was a LOT of RAM, know that we never used two ASCII chars to store a year. We used a single byte to store the offset from 1900 in binary. So there will be no overflow until 2156.
Lots of organizations worked hard to prepare for Y2K. Lots of other organizations did absolutely nothing to prepare. Neither had any significant problems on 1/1/2000. The reason is there were very few problems to begin with. The myth was that back when memory was precious, programmers stored the year in two bytes instead of four.
While I'm sure plenty of organizations did nothing and were fine, I know for a fact that storing years as two bytes was not a myth. At my organization I fixed such a problem in critical systems. We would have had people collecting GPS data in the field with no way to verify it's quality if I hadn't. Not doom for our organization, but not a "myth" as you call it.
Most TRS-80 operating systems figured 3 bits was enough to store an offset from 1980, so we've already lived through the Y1.988k bug.
Well... My "out of the box" (ie. no special tweaking) Linux on my laptop did accept it...
I had to remove tick & tock.usno.navy.mil from my NTP config.
Actually, most TRS-80 operating systems didn't even keep TRACK of time. It's the Disk Operating System (LDOS) that you're talking about. The TRS-80 didn't even have a built in clock / timer board / dedicated bits or bytes for knowing the time. And Level I and Level II Basic on it don't ask about the time or save it on the cassette tape system. And neither did the Apple ][+. You had to buy add-in clock boards to keep track of the time.
Even the IBM PC did not have a real-time clock until the IBM-AT version in 1984. [Thank you wikipedia for prior info]. If you boot up an old IBM machine, one of the first things that the system asks after boot-up is to enter the time and date. [actual info from turning the old computers on in the garage].