Szökőmásodperc rendszerösszeomlást okoz? Vagy más?

Linux-haladó

Ezt olvastam: http://serverfault.com/questions/403732/anyone-else-experiencing-high-r…

Úgy tűnik, többeknek sokféle gép összeomlott, és az emberek találgatnak, mi lehet az oka. Úgy vettem ki a kommentekből, hogy a szökőmásodperc kezelésére gondolnak, de volt, akinek biztosan nem ez okozta a gondot.

Mindenesetre nekem nem egyértelmű, mi okozta a gondot.

Nekem három gépem van, amik folyamatosan mennek, ezek egyike sem omlott össze.

G

  • 9505 megtekintés

( kaltsi | 2012. 07. 01., v – 01:03 )

Ha az okozta volna a gondot, akkor egy sima ntp szinkronnál is összeomlana, hacsak nem az ntp server omlott össze.
Itt 14 linux server van és egyik sem omlott össze.

Nekem is gyanús... egyfelől szerintem nem lehet az ntp dolga a szökőmásodperc kezelése, hanem a kernelnek kell tudnia ezt. Egy hálózathoz nem kapcsolt gépen is tudnia kell a rendszernek, hogy ma egy másodperccel több van, mint egy átlagos napon.

De láthatóan többeknek többféle gép valamiért mégis összeomlott.

És nem április 1 van :-)

Én azt várnám, hogy valami konfigurációs fájl ezt tartalmazza. Ugyanúgy, mint amikor pl. megváltozik a téli/nyári időszámítás dátuma, arról is értesül a rendszer időben.

Persze ha a szökőmásodperc idejét nem lehet előre tudni jóval, csak pár órával, mondjuk, akkor nem szóltam.

Kb. fél évvel előre lehet tudni. A téli/nyári időszámítás váltását általában a tz/zoneinfo adatbázis tartalmazza. De egy kernelnek egy ilyen adatbázisról (futásidőben updatelendő csomagról) miért kéne tudnia? Ez egy afféle time service feladata, nem kernel dolog szerintem. A kernelnek mindegy, az időben mikor történt ami történt, főleg mivel nem real-time kernelek. Real-time kernel esetében is a lényeg az eltelt idő mérése, nem a falióra szerinti idő ismerete (elapsed time vs. wall clock time).

Jó, akkor most miről beszélünk? Nem értem.

Ha a kernel az 1970 január 1 óta eltelt másodperceket számolja kizárólag, akkor az, hogy a következő másodperc szökő vagy nem, az nem számít semmit.

Gondolom van valami rendszerhívás (gondolom libc), ami a másodperceket átszámolja év, hónap, nap, óra, perc, másodpercre localtime-ban. Ez már mindenképp használja az időzóna információt, mert egyébként nem tudná, hogy itt éppen mennyi az óra.

Ezzel csak azt akarom mondani, hogy vannak gépek, amiken nincs ntp, és bizonyára azoknak is tudniuk kell azt, pontosan, hogy x másodperc az hány óra hány percet jelent.

Emellett nem értem még mindig, hogy az ntp hogyan "szúr be" szökőmásodpercet a kernelbe. Ha x másodperc volt eddig (12 óra 59 perc 59 másodperc), akkor utána jön az x+1-ik másodperc, ami 12 óra 59 perc 60 másodperc, és utána jön az x+2-ik.
Én legalábbis így képzelném el.

És azt meg már meg sem merem említeni, hogy azt végképp nem értem, ez hogyan okoz rendszerösszeomlást, vagy programok hibás működését, de persze bizonyára valaki valamit hibásan írt meg.

Az időszinkronizáció azért ennél cseppet bonyolultabb. Gondolj csak a siető órák visszaállítására.
A szökőmásodperc pedig nagyon egyszerűen okozhat problémát. Elég egy időzítést erőteljesen használó függvény(objektum), amely mondjuk egy listával dolgozik. A listaelemek időbélyeggel ellátottak. Ha az aktuális idő nagyobb, mint a listaelem ideje, akkor az a művelet végrehajtásra került. Egy másik függvény törli a végrehajtott műveleteket a listából. Ha beteszed a szökőmásodpercet, akkor könnyen átugorhatsz műveleteken, ami maga után vonja a hibás működést. Márpedig ha egy ciklus hívja meg ezt a függvényt, akkor könnyen végtelen ciklus lehet belőle. Így kész is a 100%-os cpu terhelés.

A szökőmásodperc pedig nagyon egyszerűen okozhat problémát. Elég egy időzítést erőteljesen használó függvény(objektum), amely mondjuk egy listával dolgozik. A listaelemek időbélyeggel ellátottak. Ha az aktuális idő nagyobb, mint a listaelem ideje, akkor az a művelet végrehajtásra került. Egy másik függvény törli a végrehajtott műveleteket a listából. Ha beteszed a szökőmásodpercet, akkor könnyen átugorhatsz műveleteken, ami maga után vonja a hibás működést.

Erre írtam, hogy "persze bizonyára valaki valamit hibásan írt meg."

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Hat, ez eleg nagy kretenseg. Marmint ez a "ja, akkor kicsit gyorsitsuk/lassitsuk be az orakat". Miert pont egy napig? Mi van akkor ha valakinek tenyleg abszolut ido kell es nem csak ilyen primitiv szarsag hogy "mi volt elobb v. kesobb"? 

Soha nem ertettem hogy az eleve rohadt nagy (~4 megas) zoneinfo/tzdata-hoz hasonloan miert nem birnak beletenni egy plusz ~tucatnyi relevans sorbol allo valamit, ami megmondja hogy "na, epp TAI-ban mennyi a szokomasodperc, levonjuk azt, oszt aldas, megvan az UTC"? Az NTP meg ugyahogy tamogatja ezt ha kezzel letoltogetjuk ezt a filet alkalomadtan es periodikusan belerugunk, de... de akkoris. 

Es akkor nem kell ilyen egetvero faszsagokat csinalni.

Már csak egy a kérdés: mi az az "abszolút idő"? És mihez képest? :-D

Az időszámítás egy megegyezés, nem több.  Ráadásul elég korlátozott műveleteket lehet rá értelmezni. Nem lehet az időt négyzetre emelni, köbgyököt vonni, sem két időt összeszorozni. Ha ez megvan, akkor már érted a "wall clock" olyan értelmezését, amikor a zember csak ránéz az órára.

Tehát marad az időre vonatkozó műveletek értelmezése:

Reláció: egy időpont kisebb, egyenlő vagy nagyobb, mint a másik. Ezekre általában a megegyezés szerinti idő vonatkozik.

Különbség: egy időponthoz képest egy adott különbséggel képzett időpont. Szintén a megegyezés szerinti időre vonatkozik.

Itt a vége.

Pontosabb időzítésekre soha nem a wall clock-ot használjulk, hanem pontosabb dedikált időzítést. Ez az entitás az ő tulajdonságainak megfelelő pontossággal képes az időt vagy időintervallumot  mérni.

És ebből következhet a megegyezés szerinti idő "mégiscsak hasznáhatósága". Ha a szökőmásodperc(ek) miatt okozott "időnyúlás" hibája olyan kicsi, ami még megfelel az adott felhasználás pontosságának, akkor a megegyezés szerinti idő is felhasználható pl. egy intervallum mérésére. Ha nem felel meg, akkor jöhet a pontosabb időzítő.

Példa: Legyen a szökőmásodpercek száma 5. (Elég sok!)

Az adott nap bármely két időpontja között a hiba <58ppm. Ha nem lenne elosztva egy napra, akkor "időugrás" lenne.

Ennél pontosabb időt pl. egy gondosan hitelesített és stabilizált kvarc időalappal lehet elérni, egészen 0,01ppm-ig.

Még pontosabbat már csak atomórával.

Az időmérést végző eszköz felbontása sem mindegy, hiszen egy DCF77 "atomóra" szinkronját legfeljebb másodpercenként tudod megszerezni. Pontosan ezért van egy rendes számítógépben óra, intervallum időzítő és nagyfelbontású időmérő eszköz egyszerre. És mindig tudni kell, melyik alkalmas az adott feladathoz! Egy éves határidőnél tökmindegy, egy karóránál is szinte, a GPS-hez meg ps pontosságú időzítés kell.

Már csak egy a kérdés: mi az az "abszolút idő"? És mihez képest? :-D

Ezen kar rugozni, mert mar gyakorlatilag fel evszazada kitalaltak elottunk. 

A problema meg abbol all, hogy ugyan egy eszkozon belul ugy hellyelkozzel meg ha meg is  tudod oldani a problemaid (relacio, kulonbseg, amiket irtal is, teljesen jol), ket, vagy annal tobb ezkoz eseten hogy csinalod ha csak ugy bele a vakvilagba mindenfele random hulyesegeket otlenek ki az emberek ahelyett hogy azt hasznalnak ami igy van es adott es mukodik? Lasd ez az "egy nap alatt majd behozza a lemaradast" szintu istenbarma megoldasok. Mert igen, az ugy arra lehet hogy jo hogy kiscicas videok streameleset idobelyegezd, vagy hogy egy sleep()/usleep()/nanosleep()/select() ne csinaljon akkora baromsagot mint amekkorat csinalhatna ezek nelkul, de... de kb masra nem igazan - es leginkabb akkor ha ket eszkozt akarsz osszehasonlitani. 

Es hat igen, ennek a merese (azaz hogy "mennyire stabil az orad") mar szinten nem egy egyszeru feladat abszolute idealis esetben is (azaz mindenfele baromlasok nelkul).

2 eszköz esetében is csak akkor van gond ha mindenáron abszolút időket akarunk összehasonlítani. Intervallumokkal semmi gond. (Pl.: ping 200 ms-on belül tök jól tud működni különböző eszközök között monotonikus órákkal.)

Abszolút idők esetében érdemes észnél lenni. Pl.: a napokat time_t esetében definíció szerint megkapod, ha 86400-zal elosztod. Ebből következik, hogy a szökőmásodperc az tipikusan 2-szer van elsütve éjfélkor. Rengeteg kódban gettimeofday van használva intervallum mérésre: ritkán, de csúnya hibák alattomos forrása (pedig C-ben is ott van a clock_gettime, CLOCK_MONOTONIC-kal).

https://naszta.hu

Mondom, hogy kevered a szezont a fazonnal. ;)

A sleep()/usleep()/nanosleep()/select() - ezeknek köze nincs a szökőmásodperchez, meg még a nyári időszámításhoz sincs.

A "mennyire stabil az orad" hasonló eset, mert ott a mértékegység ps és fs (femtosecundum) nagyságrendben van, és egészen másról szól.

Folyamatok szinkronizálása akár eltérő órajelek esetén is lehetséges, mer jól kidolgozott technikák léteznek az ilyen problémákra.

Amiben tényleg igazad van, ha baromarcú programozott valamit - no, arra tényleg nincs megoldás. De csak ennyi, és nem a "rendszer" hibája.

Tisztázzunk néhány dolgot!

Osztályom utoljára a gimnáziumban volt. ;)

A sleep() és társait nem én irtam, hanem egy hozzászólással feljebb keletkezett.

Aztán úri kedvemben miért ne használhatnék sleep-et?

A (futás)idő mérésére az órát használni (azt az órát, amit a szökőmásodperc cseszeget) elég nagy marhaság lenne. Nem véletlen, hogy egy számítógépben (pécé vagy nagyobb), de még a mikrokontrollerekben is külön hardver van az óra (rtc) és az időzítések kezelésére.

Kifejezetten futásidő mérésére külön hardver is létezik. Amit én használtam utoljára, az a POWER processzorokban egy olyan számláló, amit a CPU órajele (throttling nélkül, ha van olyan) inkrementál. Ha egy regiszter kiolvasása "nagyon félremegy", akkor elromlott a processzor. ;) Intel + Microsoft megoldás is van. Ezeknek sincs köze a szökőmásodperchez.

Maradjunk annyiban, hogy ami "nagyon félremegy", azt szoftveres írta. :-D

Kíváncsi lennék a tőzsdéken a nanosec nagyságrendű játékpenzes tranzakciókhoz mi vasat használnak, mikor a mese szerint 2-3 évtizede még abból is rinyálás volt h. a tőzsde szerveréhez való linken milyen hosszú volt az optikai kábel, és ne legyen ebben eltérérés a kereskedők között.

Szerintem kevered az abszolút időt a relatívval. A real time kernel is nem attól lesz real time, hogy az időt hogyan méri.
A kernelnek (csak 2 példa) biztosítania kell a sorbarendezhetőséget és a kauzalitást. Ehhez pedig nagyon pontosan kell az időt nyilvántartani. Azt is meg kell oldani, hogy az órát(relatív időmérés) sose állítunk vissza, ha siet, akkor valamilyen technikával biztosítani kell a lassulást. Márpedig ez mind a kernel hatásköre.

Egy rendszerben, ami nem real-time, tehát ahol az egyes taszkok lefutásának semmilyen valódi időbeli megkötése nincs, értelmetlenség arról beszélni, hogy az időt nyilván kell tartani. Nyilván kell tartani egy monoton növekvő számlálót, de annak semmi köze nem kell legyen ahhoz, amit mi időfogalomnak nevezünk. Önmagában egy kernel a processzütemezéshez egyáltalán nem kell, hogy tudjon arról, mi a valós idő a számítógépen kívül. Semmi köze hozzá.

( turul16 v | 2012. 07. 01., v – 06:40 )

on-call vagyok, kb 100 geprol tudom, hogy leszartak, beleertve a linuxos kutyueimet is, bar 3.1..3.2 verzio kozott egyik sincs.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Igen, 1 percen belul nem kert jelszot, connect talan ment.
Localisan sem.

A gepen akkor futhatott meg, virtualbox es tobb java process is, ulmint van max user processre ill. memoriara, nem daralt a vinyo.
kb. Jun 30 05:20:01 -kor adta meg magat.

A tobbi cuccon a hiba elotti (de termeszetesen stabil patchekkel) vagy utani verzio van.
1 May 2008 -ota van a hiba, ill. 23 Mar 2012 -ban lett fixalva.

2008. dec. 31 -kor vajon triggerelodott -e a bug ? Akkor volt leap sec ez elott.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ugyan nem Gentoo, hanem CentOS, de 76-os load volt rajta. (4db tomcat baxta a rezet - Atlassian). Egy kicsit lassabb volt az ssh bejelentkezés mint szokott, de teljesen reszponzív volt a cucc. Gentoo-s gépeink nagy load-nál is sokkal reszponzívabbak, mint az egyéb disztó(in)k.
Szóval, valszeg ott más gond (is) lesz.

( errotan v | 2012. 07. 01., v – 09:13 )

Nekem gondot okozott a "szökőmásodperc", újra kellett indítani minden gépet, mert olyan progi ment rajtuk amelynél az időzítés nagyon fontos volt. Hiába indítottam a progikat újra akkor is ették a procit ( 40% a 0,01% helyett :) ) az egész gépet újra kellett indítani.

Nálam is ez volt a helyzet, konkrétan az összes java tekerte a cput és szórta az interruptokat. A megoldást itt találtam meg: http://planet.mysql.com/entry/?id=33709
A date parancsnál a date -s "`date '+%D %T'`" -t használtam, mert az ott leírt módon nem ette meg. Utána ntp újraindít és a probléma megoldódott.

( csuhi | 2012. 07. 01., v – 09:49 )

Debianokat érinti csak a hiba?
Nálam Centos5-ök, SL6-ok és Fedorák vannak, nem észleltem semmi problémát.

--
http://csuhai.hu

Oké, az kiderült számomra hogy a debiant érinti, csak az nem hogy más disztrókkal mi a helyzet. Csak azért kérdem mert gyorsan ránéztem pár desktopra, szerverre és virtuálgépre ami egyik sem Debian vagy származék, és nem észleltem problémát. Álljak-e le komolyabban vizsgálódni?

--
http://csuhai.hu

Persze, hogy fut. Csak túl látványosan, kicsit nagy villanyszámlát csinálva. :D

Különben lehet kételkedni abban, hogy nálam előjött a probléma, csak minek. Tényleg belefutottam, s zaklatottságomban írtam is egy post-ot, igaz, nem ide, aztán itt linkeltem azt.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem arról beszéltem, hogy leállt volna. Az oprendszer stabil maradt. Amikor jött a szökőmásodperc, a gép be volt kapcsolva, a mysqld pedig elkezdte felzabálni a futásidőt. A mysqld-t leállítottam, s akkor vettem észre, hogy a firefox 115 % - 1 CPU magra vonatkoztatva - futásidőt eszik. Mindez egy up to date Fedora 17-en. Ntp szinkron van. Nyilván, akinek éjjel 2-kor ki volt kapcsolva a gépe, semmit sem tapasztalt.

Gondolom, vannak a hiba megjelenésének egyéb, speciális feltételei is.

Fedora Core 3 nem régi egy cseppet? :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Fedora Core 3 nem régi egy cseppet? :)"

reginek regi, de ami mukodik, ahhoz nem nyulunk, mert azzal is csak bonyolitjuk az eletet :D) majd ha kihullik alola a vas, akkor lesz mas.
azt meg már be se mertem irni, hogy van egy RH 7.3 is meg az ozonviz elottrol, koszoni szepen az is jolvan. Lehet azert, mert postgres fut rajta :D)

( calamari | 2012. 07. 01., v – 10:13 )

Az Xmarks is ezért van szanaszéttörve vajon már órák óta?

( janoszen v | 2012. 07. 01., v – 11:57 )

Nekem a Tomcat elkezdte zabálni a CPU-t, a strace meg egy rakás futex() hívást mutat connection timed out hibával.

( arpi_esp v | 2012. 07. 01., v – 18:17 )

nekem sehol nem jelentkezett hiba, pedig van java-s es mysql-es gepem is eleg, mind ntp-vel

A'rpi

( Hunger | 2012. 07. 02., h – 00:58 )

Halkan jegyzem meg, hogy amikor az MS lófasz - abszolút nem üzletkritikus - Zune lejátszójával volt hasonló probléma, akkor nagyobb trollkodás ment a témában... ;P

( VaZso v | 2012. 07. 02., h – 14:45 )

Nekem egy fizikai gépen és egy VPS-en jelentkezett a dolog tegnap - egyiknél MySQL, másiknál Java tekerte a procit.
Dátumállítás megoldotta mindegyiken.

Másik két VPS-t meg a szolgáltató indította újra még hajnalban /lehet, több VPS is megkergült náluk.../, bár azokon (és néhány másik gépen) nem nőtt a terhelés, nem jelentkezett a probléma - igaz, a fentiek közül egyik program sem fut rajtuk.

Mindegyiken Debian rendszer van.

( lzrd | 2012. 07. 02., h – 21:49 )

Nekem meg az androidos telefonom ette meg a procit. És a telefon mellé támasztott bringát is.
--
unix -- több, mint kód. filozófia.
Life is feudal

( Cybernet | 2012. 07. 02., h – 22:17 )

Pedig létezik.

Nangyon nem mindegy, hogy az időt hogy állítja a szerver magának.
a, cron: ntp nasa
b, open-ntpd

Az "a" megoldással nekem a dovecot omlott össze egyszer, amikor nagyot ugrott a szinkronizálásnál.
A "b" megoldás sokkal szebb, dovecot is azt javasolja, teljesen más mechanizmus.

* html {display: none}

( uid_16401 | 2020. 12. 31., cs – 17:10 )

Mivel 2016 óta nem volt UTC korrekció, hamarosan várható a következő. Vajon megmaradtak a bugok, vagy javították már azokat?

( debtamas88 | 2021. 01. 02., szo – 02:04 )

Rengeteg eszközön a 2038 évnél tovább nem lehet dátumot beállítani - ezt nem is fogják javítani már azokon.
(year 2038 problem)
"Ej, ráérünk arra még!" :D

Nem érnek rá, mert már most vannak olyan rendszerek, amik jövőben dátumokkal dolgoznak, számolnak előre, azok máris belefutnak. Nem a ráérés miatt nem lesz javítva, hanem a gyártók lustasága miatt, csak addig fontos nekik az ügyfél, amíg a c4rjukat megveszi, utána már terméktámogatás, meg javítás nem jár, vegyen újat. És ez nem tervezett elavulás, mielőtt hajbazer jönne, nincs ezen semmi tervezve, egyszerű ménkű lustaság és nemtörődömség.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

De, megoldja, a 64 bites rendszerek már azt használnak, és a 32 bites Linux/BSD kernelekbe is van már rá folt, de a régi, int32-őt használó progikkal inkompatibilis (vagy ezen 32 bites alkalmazások felé kompatibilitásból int32-őt jelez továbbra is, ami bugos). Pont ez a lényeg, hogy ilyen beépített eszközök gyártóit nem érdekli, hogy mi oldja meg, nem nyúlnak hozzá. Megvetted a szutykukat, pénzed begyűjtötték, onnan nem vagy fontos többé, max. a marketing részlegnek, ha új eszközt vennél.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”