NTP Glitch Reverts Clocks Back To 2000 179
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."
Re:Not an NTP glitch (Score:4, Interesting)
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.
Re:Maybe they could improve the algorithm? (Score:3, Interesting)
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.
Re:Maybe they could improve the algorithm? (Score:4, Interesting)
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
Re:The Y2K bug was REAL (Score:5, Interesting)
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.
Re:The Y2K bug was REAL (Score:2, Interesting)
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.
Re:The Y2K bug was REAL (Score:4, Interesting)
Most TRS-80 operating systems figured 3 bits was enough [trs-80.org] to store an offset from 1980, so we've already lived through the Y1.988k bug.
Re:Not an NTP glitch (Score:2, Interesting)
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.
Re:The Y2K bug was REAL (Score:4, Interesting)
Even the IBM PC did not have a real-time clock [wikipedia.org] until the IBM-AT version [wikipedia.org] 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].