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

 ( gee | 2012. július 1., vasárnap - 0:45 )

Ezt olvastam: http://serverfault.com/questions/403732/anyone-else-experiencing-high-rates-of-linux-server-crashes-today

Ú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

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

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 :-)

"hogy ma egy másodperccel több van, mint egy átlagos napon."

Ezt hogy érted?

Szökőmásodpercről volt szó. http://en.wikipedia.org/wiki/Leap_second

A kernel honnan tudna, mikor dontott ugy az IERS, hogy szokomasodperc lesz?

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

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

Sajnos az ntp szétesett, és vélhetően emiatt pár ms sql-t kezelő alkalmazás megzakkant.
hogy csak az esemény esett egybe, vagy tényleg van köze, azt nem merem kijelenteni 100%-ban.

Az a gyanúm, ide való:

http://hup.hu/node/115849&comments_per_page=9999#comment-1477731


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

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.

3.2.2-gentoo -s gepre ma nem tudtam bejelentkezni, reboot. mysql ill ntp van rajta. Maskor ilyent nem csinalt, lehet osszefuggesben van.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

és ssh-n keresztül nem tudtál bejelentkezni?

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.

Akkor is volt egy hiba benne, amit ilyenre sikerült javítani... :)

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.

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.

Nálam a linken lévő megoldás segített, újraindítás nélkül megoldja.

Java es BIND. :)

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

--
http://csuhai.hu

Nálam debian 6 van, fenti fix után a mysql nem tekeri a procit.

http://www.kepfeltoltes.hu/view/120701/cpu-day_www.kepfeltoltes.hu_.png

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

Fedora is érintett, s mivel a legfrissebbet használom up to date, így szinte biztos, hogy a Red Hat, CentOS, Scientific sem mentes a problémától, szóval bátran nézz csak utána alaposan!


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

egyik centos4/5 szerverem sem allt le.
sot van fedora core 3 is, az sem :D)

+1

CentOS5-ök, SL6-ok és Fedora 16-ok és 17-ek köszönik szépen, jól vannak, pedig mindegyiken fut a mysql és az ntp service is.

A Red Hat bugzillája sem tud a dologról, ntp ügyben pénteki, mysql-re rákeresve szombati a legutolsó bejegyzés.

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

Nálunk egy gép volt érintett (Fedora 12), ott a Virtualbox processz emelte meg a load-ot.

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)

Ha jól emlékszem, Red Hat 7.2-vel vagy 7.3-mal kezdtem a linuxozást. :) Ez nagyjából 10 éve lehetett, vagy több.


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

Egy openSUSE szerver alatt a Munin nem mutat semmi különös CPU ingadozást az elmúlt egy hétből, és a MySQL is rendesen működik.

--
The Elder Scrolls V: Skyrim

Redhat 6-ot is írták. És persze nem az összes Debian vagy összes Redhat.

Bár nem tudom, miért disztribúcióspecifikus.

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

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.

Nálam is volt pár ilyen. A legjobb az, hogy a VMware vCenter Appliance-be belecsomagolt, gyári, vmware-es Tomcat is eljátszotta ezt. :D

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

durva volt

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

A'rpi

jo lenne mar kideriteni hogy mitol fugg, kinel jon elo a hiba. kernel verziotol fugg? ntp verzio? csillagok allasa? nalam rengeteg kulonbozo gep kozul egyiken sem jelentkezett.

A'rpi

Nálam a két rendszer, ami produkálta a jelenséget, ezt a kernelt használja (Debian):
- 3.2.0-0.bpo.2-amd64
- 2.6.32-5-amd64

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

Most már nem.

Próbáltál kicsit találni, de nagyobbat is találhattál volna, ha nem lennél elfogult:

http://www.hwsw.hu/hirek/48180/microsoft-azure-leallas-cloud-felho.html

--
trey @ gépház

Nem olvastam, biztos nem volt hupon... (ettől még a megjegyzésem továbbra is valid ;)

Várd ki a végét. Még csak most indul :D

--
trey @ gépház

Majd mindjárt rásegítek... >;P

Ööö... CentOS, csomó Java process, fut az ntpd, de nem tapasztaltam ilyesmit: http://munin.javaforum.hu/hu/javaforum.hu/index.html#other

FreeBSD-n se szaladt meg a JBoss... egyéb helyen rálátok egy csomó RHEL-re, amiken mindenféle Java cucc fut, ott se volt baj...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Új Debian, Java, 40-es load, ette a procit rendesen.

--
Gábriel Ákos

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.

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

Neked is eltekerte magát a bringád?

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}

Az egyik szerveremen pont ma hajnalban holt hamvaiba a dovecot.
Aszonta, hogy 10 másodpercet ugrott hátra az idő, és ez neki fájt.
Pedig a b megoldás van használatban....nem is igazán értem, hogy a bánatba történhetett.

A dovecot nagyon rosszul kezeli, ha az ido visszafele mozog. Nem lehet, hogy el volt allitva az orad es csak idoszakonkent synceled az idot, nem folyamatosan?

kettesbe már csiszolgattak rajta: http://wiki2.dovecot.org/TimeMovedBackwards/

elvileg fut ntpd, aminek nem kéne "visszarántania" az időt, hanem csak "lassítani", hogy ledolgozza a sietést.

Érdekes, hisz azt olvastam, hogy ntpd nem egyből ugrik 10percet, hanem valahogy szépen elosztja.
De azért 10percet hogy ugorhatott ? :D

nem perc volt, hanem másodperc, de akkor is...