Leapsecond - szökőmásodperc

 ( zcs | 2015. június 27., szombat - 22:56 )

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-1714386092

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

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

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Idézet:
“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.

subs

+1

Not tested by users... a probléma az, hogy a kernel még simán megy tovább, de ha jól értem, a különböző rendszerek, amik 5 rétegen keresztül egy kernel funkcióra épülnek, na, azok fekszenek meg. (linux -> java -> tomcat -> cassandra -> etc.)

> 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?

> Vagyis ilyenkor 1 mp-en keresztül a belső óra értékének egyhelyben kellene állnia. Namost ezt hogy oldod meg jól?

Az ntpd meg tud oldani cifrább dolgokat is.

--

Igazából azzal se járnánk jobban, ha fordítva lenne. :)

https://www.youtube.com/watch?v=Uqjg8Kk1HXo

Szerintem ez kurvára egyszerű: vagy az ntp "húzza" az órát mondjuk 1 napon keresztül annyival, hogy pont kiadjon egy másodperc diffit, vagy 1 másodpercig nem kap senki cpu-időt a kerneltől (ami meg egy busy-loopban vár 1 másodpercet).

Realtime rendszerben fasza kis gotcha lenne. :)

Csakhogy a linux nem realtime rendszer...

Realtime rendszer meg ne nagyon mérjen abszolút időben semmit, lehetőleg.

Java Thread.sleep regebben eleg szep dolgokat csinalt, ha elore/hatra tekerted az orat... 1.7 valamelyik updatejevel megjavult szerencsere...

Senki nem mondta, hogy elore/hatra tekergessed, azt sokan nem tolerálják.
A Oracle RDBMS pl. azonnali hatállyal megáll, ha azt észleli, hogy visszamentél az időben.

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.

linux kernel
unit teszt

Uj lehetsz errefele.

java fejlesztő biztos:D


// Happy debugging, suckers
#define true (rand() > 10)

Nálunk az összes java alkalmazásnála CPU load felment 100% és nem is ment magától vissza.

De!!! date -s "`date`" parancs megoldotta a problémát

É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...

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

Köszi, hogy szóltál.
Rákeresve egy bug report azt javasolja, hogy legalább egy nappal az esemény elött ki kell szedni az ntp szervereket, utána meg vissza.

Ja, ezt is csinálhattam volna, de kellett egy ürügy az upgrade-re :D

Elvileg 2.2(3e) mar eleg. Remeljuk mivel nalunk 2.2(4b) van tobbsegben. ;)

https://tools.cisco.com/quickview/bug/CSCus83447

Azért írtam ha már upgradelünk akkor legyen a legfrissebb stabil :) Több idegesítő bugot is javítottak benne, meg most jön B200M4 nekünk és kell a támogatásához

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.

Jul  1 01:59:59 * kernel: Clock: inserting leap second 23:59:60 UTC

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..."

Ööö... izé... miért is?

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

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...

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