GPSD Bug Will Switch Your Time-Keeping Systems To March 2002 This Weekend, Unless You Update (zdnet.com) 60
"Apparently a bug in GPSD, the daemon responsible for deriving time from the GPS system, is going to trigger on October 24, 2021, jumping the time back to March of 2002," writes Slashdot reader suutar. "There's a fix that's been committed since August, but of course not everything is up to date." ZDNet's Steven J. Vaughan-Nichols writes: This will be ugly. Or, as Stephen Williams, who uncovered the bug put it, "I have a feeling that there will be some 'interesting moments' in the early morning when a bunch of the world's stratum 1 NTP servers using GPSD take the long strange trip back to 2002." GPSD maintainer Gary E. Miller has acknowledged the problem, and a fix has been made to the code. To be exact, the fix is in August 2021's GPSD 3.23 release. So, what's the problem if the fix is already in?
Well, there are two problems. First, it won't be backported to previous releases. If you're still using an older version, you may be out of luck. Second, as Miller observed, not all distros "pick up GPSD updates or upstream their patches. [This] is a very sore spot with me." So, just because your operating system is up to date does not mean that it will have the necessary GPSD fix. Miller suggests that you check it and do it yourself: "I [am] gonna fall back on Greg K_H's dictum: All users must update."
Oh, wondering what the mysterious root cause of all this commotion GPS Week Rollover? It's a legacy GPS problem. The GPS signal GPS week number uses a 10-bit code with a maximum value of 1,023. This means every 19.7 years; the GPS week number rolls over to zero. Or, as Miller noted, "This code is a 1024 week time warp waiting to happen." So, check your systems now for this problem. And, if, like most of us, you're relying on someone upstream from you for the correct time, check with them to make sure they've taken care of this forthcoming trouble.
Well, there are two problems. First, it won't be backported to previous releases. If you're still using an older version, you may be out of luck. Second, as Miller observed, not all distros "pick up GPSD updates or upstream their patches. [This] is a very sore spot with me." So, just because your operating system is up to date does not mean that it will have the necessary GPSD fix. Miller suggests that you check it and do it yourself: "I [am] gonna fall back on Greg K_H's dictum: All users must update."
Oh, wondering what the mysterious root cause of all this commotion GPS Week Rollover? It's a legacy GPS problem. The GPS signal GPS week number uses a 10-bit code with a maximum value of 1,023. This means every 19.7 years; the GPS week number rolls over to zero. Or, as Miller noted, "This code is a 1024 week time warp waiting to happen." So, check your systems now for this problem. And, if, like most of us, you're relying on someone upstream from you for the correct time, check with them to make sure they've taken care of this forthcoming trouble.
Comment removed (Score:5, Funny)
Uh yeah... (Score:2)
Just saying.
Maybe I could to a viral dance on Tik Tok to get the message out effectively?
Re: (Score:2)
This is the Internet age. Therefore, nobody's home to talk to about this. Just saying. Maybe I could to a viral dance on Tik Tok to get the message out effectively?
Maybe, unless you account for the likelihood the attention span of the mean tik-tokker is akin to that of the fabled domesticated carp... fortunately, there's likely just enough folks paying attention that your message won't be lost.
Timewarp (Score:2)
March 2002 doesn't sound so bad...
Re:Timewarp (Score:5, Insightful)
America's biggest problems involved the previous President being guilty of adultery, and of the current President not being able to drop a bomb on Osama bin Laden. The novel cornavirus outbreak in Asia would be contained and it would be completely exterminated after infecting less than 10 thousand people. The national minimum wage was equivalent to nearly $11/hr.
I think, even at that point, I and most people would've said that the new millennium was already failing to meet expectations. But holy shit, there's "everything isn't going as well as we'd hoped" and there's "legitimately fearing a fascist coup in America."
Re: (Score:1)
I hear ya. Fortunately the FBI's plot to overthrow the government failed and the will of the people was heard. Fascist scum. Remember when they put agents into our protests to discredit them? Standard move.
Re: (Score:2)
March 2002 doesn't sound so bad...
No mobile internet? That sounds pretty bad to me.
Ha (Score:2)
And they said time travel was impossible!
Practice (Score:5, Insightful)
This is just a tiny, little practice for January 19, 2038, which will be the real-deal compared to Y2K.
Re: (Score:1)
Re: (Score:3)
There are millions (billions?) of microcontroller devices out there with firmware that is seldom touched, running on 32 bit processors, that will jump back to 1970 when that unsigned 32 bit integer overflows. Even modern ESP8266 / ESP32 devices, which are in huge number of products (especially IoT type devices) are only 32 bit. So hopefully all that software flashed onto them was written correctly...
Re: (Score:1)
There are millions (billions?) of microcontroller devices out there with firmware that is seldom touched
I totally forgot about those. I was thinking of servers and related machines..
Re: (Score:2)
That's a common problem. Lots of people only deal with PCs and don't think about the more common stuff out there. I see a baffling number of portability issues mostly due to people having no experience whatsoever with portability. Even the 32-bit to 64-bit issue on PCs is a lessened easier because little endian and lack of alignment requirements makes some of the problems just work themselves out.
Re: (Score:2)
Re: (Score:2)
2038 problems are already occuring! It's less then 20 years away. For example, we have certs for devices that must last 20 years and they are marked as expiring in 20 years. That breaks several things; internally if you just want to store as common signed 32-bit time it won't work. I've seen other 2038 issues as well. The solution isn't just go to 64-bit, as there are plenty of memory constrained 8, 16, and 32 bit devices in common use.
Unsigned 32-bit delays the problem until the next century (but stil
Re: (Score:2)
This GPS bug happens just about every year. Because different device makers assume that they're never possibly last longer than 20 years, and then 12 firmware updates and 5 models later, boom!
Lack of foresight seems to be a common problem in software, firmware, and even hardware. These are problems that occur in the future and the team that's on a tight deadline with a razor thing margin don't worry about it. Much of the time in my experience they don't even think about it. Especially if people on the te
Did someone say "time machine"? (Score:2)
It's Not a Police Box, It's a Tardis [archive.org].
Wow. Just. Wow.
Re: (Score:2)
Wow indeed, /. was a lot easier to read back then.
Re: (Score:2)
Not for me, italics bugs me. And so do the fad of anti-aliasing.
Re: (Score:1)
19 years later, we're at 44th. -- https://rsf.org/en/ranking [rsf.org]
So that's horrifying.
I guess I'll have to rely on (Score:2)
my non-internet connected stove and microwave clocks. And the 2 weight and pendulum clocks.
Al the other linux and android things like tablets and phones will probably be OK, since I'm guessing my NTP is all off of my Internet provider via cable service, since there isn't any GPS service in my home due to walls and ceilings being "too thick"
We'll see on Sunday.
Re: (Score:2)
This sounds like one of many one-man underfunded critical infrastructure projects.
Should have used the Y2K trick (Score:2)
Remember how back at the turn of the century, people kept a sliding window of years such that 00-79 meant 2000-2079? Instead of waiting until the last six months to make a patch, it might have been a good idea ten years ago for the code to simply assume that if week < 512, its not the early 2000s, and just keep updating that threshold once a year when there's a new release for some other reason. Then whoever is too lazy to upgrade still has at least ten years. But I guess that would be too easy.
It's not
Re: (Score:3)
The code does have that kind of logic. It becomes a little bit more complicated because not every system has a writable bit of memory where it can keep the upper bits of the week count.
Someone tried to be smarter (see the link to the GitLab issue in TFS) and make the moving window even larger. That code made an incorrect assumption, that a leap second would have been inserted sometime between 2017 and now, and so it turned out to be not so smart.
Re: (Score:2)
writable bit of memory
I am talking about the code itself. If the code was released in 2012, it will never see GPS telling it that the current date is 2003. Leap seconds are irrelevant, I am just talking about the interpretation of the week number from the GPS. If it is "impossibly" low, just add 1024 and continue processing.
Re: (Score:2)
Re: (Score:2)
Leap seconds are not handled from an internal list, they are handled by looking at the field broadcast by GPS satellites that gives the offset between UTC and GPS time in whole seconds.
Again, look at the bug report if you want to see exactly what the problem was. It was basically the code trying to tell the difference between now and 19 years from now.
Raspian, or Debian (Score:1)
Iâ(TM)ve got gpsd running on two of my raspberry pi units. I generally keep them updated, but only through the distribution apt system. Whatâ(TM)s the likelihood that my systems will get whacked this weekend?
Re: (Score:2)
Re: (Score:1)
If you're running version 3.23 then you're all set.
If not, then you're um... not.
Re: (Score:3, Informative)
Not looking good:
apt info gpsd
Package: gpsd
Version: 3.17-7+b1
Priority: optional
Section: misc
Source: gpsd (3.17-7)
Maintainer: Bernd Zeimetz
Installed-Size: 557 kB
Depends: netbase | systemd-sysv, lsb-base (>= 3.2-13), adduser (>= 3.34), libbluetooth3 (>= 4.91), libc6 (>= 2.28), libdbus-1-3 (>= 1.9.14), libusb-1.0-0 (>= 2:1.0.8), libgps23 (= 3.17-7+b1)
Recommends: udev, python
Suggests: gpsd-clients, dbus
Conflicts: fso-gpsd
Homepage: http://www.catb.org/gpsd/ [catb.org]
Download-Size: 249 kB
APT-Manual-Insta
Re: (Score:2)
Re: (Score:1)
Re: (Score:3)
This is the current status of the gpsd package for all the different Debian releases and supported architectures:
How Many Bits Is It Now (Score:5, Funny)
Did they up the number of bits? To 16 maybe? That way no one reading Slashdot today will be around to see it in 1256 years? (Slashdot will still be around, but encoded in nanoscale graphene inside the artificial brains of future generations of readers. But it will still be written in Perl and won't be able to handle Unicode.)
Still 10 bits (Score:5, Informative)
This was a mistake in the code that allows GPSd to guess how many times it has rolled over. It relies on comparing UNIX time, which skips leap seconds, with GPS time, which does not. Their code assumed that there would be at least one leap second in the last 4 years, which seemed like a safe bet - the planet had been spinning predictably requiring regular leap seconds every couple of years. But the planet has sped up a tad in the last few years, and no leap second have been needed, and UNIX time is a second behind where they though it would be. The logic turned out to be wrong and it will break this weekend.
Re: (Score:3)
Is this a joke? How do you cut it so close that leap seconds influence your decision whether it's 2002 or 2021 after the rollover? When you look at the current time and date, do you tell yourself, we're a second or two before the time we'd see if we were in the 2021 GPS week window, so we must be in the 2002 GPS week window? Why aren't people who do that kept away from computers?
Re: (Score:2)
Why aren't people who do that kept away from computers?
Are you saying that every spec is complete and never relies on assumptions? For over 30 years since the introduction of the leap second it has occurred more than once every 4 years. Consistently and without fail. In fact at the time GPSd was written it had occurred every 2 years. So it was a "safe" assumption to make in the spec.
As for people kept away from computers. Before you run your mouth I present to you Eric S. Raymond (yes THAT one [wikipedia.org]). He refactored gpsd completely in 2004. If you're saying Eric S. Ra
Re: (Score:2)
The bug is more than a decade younger than a refactoring in 2004. A "sanity check" was added which subtracts 1024 weeks if the week count since the GPS epoch is greater than 2180 and the number of leap seconds is between 0 and 19. If you think that assuming how many leap seconds there will be in the future is a good way to detect if a week count is plausible, instead of just looking at the current time, then I never want to hear your opinion on software matters ever again. If there aren't at least 19 leap s
Re: (Score:1)
Okay we get it. You're so much smarter than the guy who is one of the best and most respected programmers on the planet. We all bow to your great armchair.
Idiot.
Re: (Score:2)
This code literally says, if these conditions are met, then a date 18 years before this code was written is probably right, but a date a year from this patch can't be. This BREAKS live GPS for all systems because the ASSUMPTIONS don't hold, but at least it fixes some historic data from some broken GPS receivers. If criticizing that absolutely braindead code makes me an idiot in your eyes, then you are the moron I already thought you are. At least I don't pretend that I can predict how the world turns.
Re: (Score:2)
Now there are other ways, but they require some other
Re: (Score:3)
This code was never going to execute correctly on any system where it would have mattered. For the next 18 years, any system processing live GPS data would return a time in the past, i.e. before the code was written, so obviously false data. The conditions are simply bogus: It is impossible to have live GPS data which indicates fewer than 19 leap seconds and a year less than 2039, where turning the time back 19 years is the right decision. The only situation where this could have mattered is if you're proce
GPS data does not provide leap second information. (Score:2)
I'd like to ask you a question in return - Say, your computer starts, the clock reads January 1970. The only timing information you have is the output from a GPS receiver - how do you establish the time? Where, in the GPS d
Re: (Score:2)
Forget the assumption. There is no good reason for reading a week number which is not at least 19 years in the future from the time and date when the code was written, and subtracting 1024 weeks. That results in a date in the past. Even for recorded data, it outputs data which is known to be wrong: Unlike future leap seconds, the correct number of leap seconds for any given date in the past is known, so a date in 2002 with 18 leap seconds is clearly invalid data.
Sorry, GPS data does provice leap second info. (Score:2)
But we seem to have achieved a point of consensus - that leap second information is a reasonable indicator of GPS epoch, if that is all you have. Alth
GPSD's ABI stability (Score:1)
A few years ago I was trying to use Navit on Ubuntu Vivid but one day it started crashing. It turned out that GPSD changed one of its central structures without raising the SONAME. Looking deeper into it revealed that this happend several times.
I can't blame distros for sticking to an old version of GPSD if updating GPSD requires distros to rebuild every piece of software that uses it.
As long as it doesn't affect GPS coordinates (Score:2)
GPS week rollover occurred in April 2019 (Score:1)
Re: (Score:1)
When will this happen? (Score:2)
So what all is affected? (Score:2)
It would have been helpful to have example systems, commands, etc. to check for the problem.
Well, if I (don't) wake up tomorrow with the world having ended because some Russian ICBM reset back to 2002 and decided to self-launch, I'll at least know what caused it.
10 bits? (Score:1)
Seriously, 10 bits? Right after the Y2K stuff? Whoever did that needs to be identified and made fun of.
Re: (Score:2)
Keep in mind, the 10-bit number is in the GPS specification, the first satellite of which was launched in 1978, long before programmers were scurrying to fix Y2K bugs. This 10-bit rollover has happened before. A properly designed receiver is able to deal with it.
Re: (Score:1)
Keep in mind, the 10-bit number is in the GPS specification, the first satellite of which was launched in 1978, long before programmers were scurrying to fix Y2K bugs. This 10-bit rollover has happened before. A properly designed receiver is able to deal with it.
Oh. So we need to identify the new people and make fun of them. LOL.