Leapsecond - szökőmásodperc

Közösségi kerekasztal

Sziasztok, ti készültök valahogy a junius végi szökőmásodperces dologra?
Nekem ez a 2012-es balhé valahogy teljsen kimaradt, mondjuk egész 2012 homályos picit...

http://cink.hu/lassul-a-fold-forgasa-ezert-a-junius-egy-masodperccel-17…

http://www.wired.com/2012/07/leap-second-glitch-explained/

Remélem nem kell szerdán mindenhol az NTP konfigokkal játszadozni.

( BaT | 2015. 06. 27., szo – 23:43 )

“Almost every time we have a leap second, we find something,” Linux’s creator, Linus Torvalds, tells Wired. “It’s really annoying, because it’s a classic case of code that is basically never run, and thus not tested by users under their normal conditions.”

Miért is nincs akkor a kérdéses kód unit tesztelve? Nem is értem, egy kernel tipikusan az a szoftver, aminek rengeteg olyan állapotot is kezelnie kell, ami normál körülmények között "soha" nem jön elő, ugyanakkor kritikus, hogy azokat is jól kezelje le, mert egész rendszerek függenek tőle. Ezeket az állapotokat tesztekből sokkal könnyebb előállítani, és ha a kód tesztelve van, senkit nem szabadna meglepetésként érnie egy ilyen eseménynek.

> Miért is nincs akkor a kérdéses kód unit tesztelve?

Halvány emlékeim szerint a kernelfában található unittesztek száma úgy körülbelül 0.

Egyébként az a baj, hogy az egész posix szabvány el van csesszintve, ugyanis rögzíti, hogy a Unix rendszerek belső órája a szökőmásodpercek figyelmen kívül hagyásával kell hogy ábrázolja az időt. Vagyis ilyenkor 1 mp-en keresztül a belső óra értékének egyhelyben kellene állnia. Namost ezt hogy oldod meg jól?

2.6 óta soft-realtime, amibe az egy másodperces lag nem nagyon nem fér bele.

A Google módszere az, hogy húzatja az időt (leap smear), de ez azt jelenti, hogy egész nap rosszul jár az óra, ami gáz lehet ha olyan node is van a rendszerben ami más stratégiával kezeli a szökőmásodpercet. Ezt egy domainen belül bárki követheti NTP segítségével, de a kernelre kiterjeszteni őrültség lenne.

Nem olyan egyszerű ez szerintem.

( 1soproni | 2015. 06. 28., v – 07:21 )

Én végignéztem mindenhol az ntpd verziókat. ntp-4.2.4p8 -tól elvileg támogatott.
Az még kérdés, hogy mi lesz a kernelekkel...

( AiRLAC v | 2015. 06. 28., v – 09:36 )

Cisco UCS-t is érinti, ha valaki esetleg. 2.2.5a-ra upgradelve már jó lesz.

( egmont | 2015. 06. 28., v – 12:47 )

Csakhogy nehogy valaki rosszkor bontson pezsgőt: a szökőmásodperc UTC szerinti éjfélkor, vagyis magyar idő szerint szerdán hajnali 2-kor (1:59:60-kor) lesz.

( pirate | 2015. 06. 29., h – 10:25 )

Foleg a Javanak van gondja ezzel, azokat a szervereket erdemes jobban figyelni ahol java alapu dolgok futnak.
Ntpd megfelelo verziojara valo frissites utan elvileg nem lesz gond.

---
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

Nekem pár évvel ezelőttről (egy előző leap-second-nál) van emlékem hogy egy Glassfish 3.x Java 1.6 EE-vel totálisan megborult a leap-secondnál, vmi a JavaEE timerekkel (is) lehetett, illetve 100%-on pörgette a CPU-kat a glassfish.
Ha jól emlékszem leállítani se lehetett, maradt a "kill -9" :-S

De most Glassfish 4.x Java 1.7 -el (bár lehet a frisseb ntpd miatt) nem volt hasonló probléma...

( answ | 2015. 07. 01., sze – 01:19 )

Ezert kellene informatikaban TAI-t hasznalni es csak usereknek valo kiiraskor atkonvertalni az idot.