Contributed by pitrh on from the bounded leaps dept.
Christian Weisberger (naddy@) let us all know what we need to do to prepare for the impending leap second:
As you may have heard, a leap second will be upon us at 23:59:60 UTC on June 30. The sky will fall, civilization will end, and dinosaurs will roam the earth again. Well, maybe not. Neither the OpenBSD kernel nor OpenNTPD handle leap seconds in any way. So what will happen?
After the leap second, your OpenBSD system's time will be off by, well, one second. Gasp, shock. Let's say you synchronize your clock with ntpd against a server that does have the correct time. At the next poll, i.e. within about half an hour, ntpd will notice the offset and correct it, which will take a few minutes. That's it. (I expect ntpd will drop down to a short poll interval and the frequency correction will fishtail a bit since it's a differentiator reacting to a jump.) Unless you obsessively watch your ntpd, you won't notice a thing. All the terrible things you may read that might happen, or that did happen to Linux in the past, are side effects of systems that do attempt to handle leap seconds, so that they always have the correct time at the price of a confusing extra second popping into existence. Finally, if you are one of the exceedingly few people for whom the clock being off by a second actually matters, then I'm pretty sure you also know how to deal with it. PS: Any hate mail about leap seconds should be directed to (1) the people who insist that Earth's celestial wobbling around must have primacy for time keeping and (2) the people at POSIX who specified that time_t must not include leap seconds, which means we can't just let the time zone database handle this.
So, once more, the answer is: don't worry, OpenBSD does the right thing. Thanks to naddy@ for taking the time to let us know.
(Comments are closed)
By Anonymous Coward (176.10.104.243) on
By Bob Beck (37.0.204.144) beck@openbsd.org on
By Bob Beck (37.0.204.144) beck@openbsd.org on
By Anonymous Coward (86.169.107.168) on
No, OpenBSD doesn't do the right thing. It does a practical but wrong thing. That's what the answer pretty clearly says. So maybe take off your fanboy hat for (the leap) one second. It might be practical for many consumers. But if you (exceedingly few, really?) really have to worry about time then the solution is not to use OpenBSD and pick a system that actually does the right thing.
Comments
By Anonymous Coward (92.246.18.44) on
>
> No, OpenBSD doesn't do the right thing. It does a practical but wrong thing. That's what the answer pretty clearly says. So maybe take off your fanboy hat for (the leap) one second. It might be practical for many consumers. But if you (exceedingly few, really?) really have to worry about time then the solution is not to use OpenBSD and pick a system that actually does the right thing.
There is a specification, it is being followed. Works as specified.
By bee with fanboy hat (146.212.105.108) on
No. It does exactly the right thing and the article even tells you why; as long as time depends on an external factor, you can't handle that in a sane way. Suppose something happened to Earth's rotation and you would have to add arbitrary number of seconds.
If you still feel the same way, please feel free to show us the code that can handle the time of 23:62:03 .
Comments
By Anonymous Coward (86.169.107.168) on
If there ever was a need to introduce more than 2 minutes of leap seconds on a single day then humanity would have far more existential issues than computer time...
By Chas (147.154.235.102) on
For anyone needing highly accurate/extreme precision time, the natural move would be to disable openntpd and revert to the reference distribution. For many others with no objections to a few seconds drift, they obtain a simpler, more rugged, and more secure daemon.
How is chrony handling this? It appears that systemd is also dispensing with the reference ntp daemon. Declining market share may be present an opportunity for reference ntp to make some architecture changes.
Comments
By Anonymous Coward (2601:186:4180:61:c4ac:685c:a0c7:c5c3) on
Isn't that what ntimed is all about?
https://ma.ttias.be/ntimed-ntpd-replacement/
Comments
By Chas (147.154.235.102) on
Isn't that what ntimed is all about? https://ma.ttias.be/ntimed-ntpd-replacement/
I was not aware of this project. I find the ntpd commentary quite interesting. I wish them luck!
x Why not fix NTPD? PHK tried. But there are 360.000+ lines of code in NTPD.
"NTPD is doomed": refactoring would not be time or resource efficient, hence the start of Ntimed. From the ground up, a good security architecture.
Is NTPD safe? Right now: yes, most likely. Long term: no.
NTP is probably the oldest code still running on the internet
Ntimed [is] something to keep an eye on, before the ticking time bomb of NTPD bites us all.
By Shane J Pearson (27.32.243.218) on
>
> No, OpenBSD doesn't do the right thing. It does a practical but wrong thing. That's what the answer pretty clearly says. So maybe take off your fanboy hat for (the leap) one second. It might be practical for many consumers. But if you (exceedingly few, really?) really have to worry about time then the solution is not to use OpenBSD and pick a system that actually does the right thing.
Which system does the right thing?
The solutions I have seen each have their own drawbacks. Suffer drift by stopping NTPD and then restarting after the flag and then suffering a step or slow adjustment? Suffer a two second second? Suffer a code change to allow for 61 seconds in a minute, throughout your entire OS and application codebase? Preemptive slow adjustment?
Your method of getting the square peg into the round hole is the right way when the others are wrong? They each suck in their own special way, no?
By Anonymous Coward (173.174.38.161) on
http://community.arubanetworks.com/aruba/attachments/aruba/unified-wired-wireless-access/49619/1/ARUBA-PFB-20150430_Leap_Second_Field_Bulletin_Rev-3.0511.pdf
By Just Another OpenBSD User (77.85.139.241) on
Now you face inaccurate time before the event with an unpredictable degree of uncertainty for a while and on top of that program errors. Because we all know for a long "time" from other areas: most people can't count unless using fingers when creating programs. Including TV schedule programming.
Then again, why not create "another" time scale with a new set of incompatibilities in a Linux fashion, no thanks. OpenBSD's OpenNTPD does the right thing, as expected.