Random szerverhalál

Linux-haladó

Sziasztok!
Adott egy Debian Lenny szerver, ami kb 3 hónapja azzal szórakozik, hogy random lefagy. A konzolon a következő üzenet olvasható különbféle process-ekkel, szépen sorban:
"INFO: task x:y blocked for more than 120 seconds"
Van hogy elmegy egy hétig is, van hogy csak másfél napot bír. Iszonyatosan idegesítő, mert egy mail szerver.

memtest hiba nélkül lefutott rajta, próbáltam apache modulokat ki-be kapcsolgatni, kernelt fordítottam rá, alap kernellel próbálkoztam, de egyszerűen nem tudok rájönni, hogy mi lehet a hiba. Érdekes egyébként, hogy tudom váltogatni a konzolokat, tehát a kalviatúra él, azonban egy karaktert sem tudok beírni. Ti mit tennétek a helyemben? Mivel próbálkozzak? Természetesen a logokból semmit nem tudok meg, mert ugye ahogy lehal, nem logol semmit. Másrészről munin-nal is figyelem az eseményeket, de ott sem látszik semmi. Egyszerűen nem tudom mit csináljak... Ötlet?

Előre is köszi!

  • 1800 megtekintés

( Lacyc3 v | 2010. 03. 07., v – 19:29 )

64 bites rendszer <= 2.6.27 -es kernellel? Ha igen, akkor frissítsd a kernelt 27+ -ra szerintem, nem láttam frissebb kernellel ilyen bugot (vagy csak nem néztem jól szét).

Upd. Bocs, sokat tököltem a hsz-el, nem aktuális.

( pgabor v | 2010. 03. 07., v – 19:46 )

fentebb látom, meggyőződtél róla, hogy nem támadás. én hardver hibára gyanakodnék.

Igen, kernel bug, de elvileg a '26-os óta javítva kell hogy legyen (legalábbis az Ubuntu-s bugreportok szerint). Nem (jól?) csurgott volna vissza a folt?

Mindenképp érdemes megpróbálni. Emlegették, hogy BOINC futtatása közben gyakrabban előjön a hiba. Tesztként én is elkezdtem futtatni (újra..), a '31-es (igaz Gentoo) kernellel eddig nincs probléma.

( gthomas | 2010. 03. 07., v – 21:24 )

Szia, nekem olyan volt (igaz, vmware alatt), hogy minden megfagyott, de az nginx ment - a timesource acpi volt rossz, timesource=pit a grub-ba megoldotta.

( Husky | 2010. 03. 07., v – 21:41 )

Ah, ugyanezzel én is szívtam az elmúlt néhány hétben.
Teljesen jól ment a szerver fél évig, majd rákerült egy adatbázis amiben 1-2 percenként meg kell mozgatni 8-10 millió sort. Eredmény: kb naponta/félnaponta belock-olta magát.

2.6.32-gentoo-r5 volt rajta, néhány TB diszk raid5-ben, azon LVM, azon ext3. Magas load és sok I/O mellett jött elő. Forgattam néhány kernelverziót (más FS, multicore raid kikapcs, stb), de nem oldotta meg.

Aztán most pénteken tettem rá 2.6.33-at. Azóta megy, jól. Belegondolva hogy milyen sűrűn jött elő, gyógyultnak mondanám.

Szóval - 2.6.32: mégnemjó. 2.6.33: jónaktűnik.

Elég random az előfordulása, gyanítom hogy több lock összeakadása kellett hozzá. Ami úgy tűnt hogy összefügg vele: x64, sok I/O (FS, LVM, RAID), magas load, multicore raid, ütemező. A panic dumpok jellemzően ext3/raid trace-eket mutattak mindig.

Hagyom járni a vasat még néhány hétig a mostani felállásban (hátha megfagy még), utána vagy megpróbálom visszakapcsolni a multicore raidet (a régebbi próbálkozások után kb az maradt még kikapcsolva), vagy rálegyintek hogy az annyira nem is kell, és sosem derül ki hogy az, vagy a 2.6.33 hozott végül javulást. :)

Majdnem. :)

Azt jelenti, hogy nincs még annyira kitesztelve hogy nyugodtan rámondják: stabil. A 2.6.0 és 2.6.20 között viszont volt egynéhány apróság ami (nekem) segített rájönni, hogy csak a korrektebb fejlesztők merik odaírni az új funkciók mellé: Experimental. Az ő munkájukat így én merem tesztelni. (A többiekét pedig akaratlanul, épp csak közben azt hiszem róla: stabil. Pedig nem feltétlenül.)

Most pl nagyon úgy áll, hogy szerencsétlen multicore raidnek köze sem volt a fagyáshoz, és csak óvatosságból szedtem ki (BTuning gyári kernelében pl benne sem volt, aztán mégis ráfutott).

( BTuning | 2010. 03. 13., szo – 17:09 )

Sziasztok!

Továbbra is esik, kel az egész rendszer. Viszont észrevettem, hogy a 16 GB RAM-ból, hol 9-et, hol 12-t, hol 15-öt, hol mind a 16-ot látja a Debian. (Természetesen úgy, hogy mindig ugyanazt a kernelt indítom.) BIOS meg mindig látja mind a 16-ot. Ezzel lehet valamit kezdeni? Nem lehet, hogy ez okozza az egész zűrzavart a rendszerben?

Üdv!

ennyi szerintem még sok is :)

az ilo-ra nézzél be (remélem van olyanod), és olvasd el a logokat. ha hw hibád van, jó eséllyel benne lesz az ilo logjaiban.

egyébként én bizony a kernelt gyanúsítanám. próbálj szerezni valami frissebb kernelt (inkább .33 mint .32, de .32-nél semmiképp nem régebbit), és a bleeding edge/experimental funkciók számát mérsékelni. ha használsz lvm-et snapshottal, akkor min. .32.9 legyen a verziód.

( BTuning | 2010. 03. 29., h – 11:23 )

Sziasztok!

Nos végülis megoldódott a probléma. Alaplap és tápegység csere, plusz egy 2 GB-s memóriamodul is kukás volt a 8-ból. Egyszer kifagyott, kikapcsoltam, utána képtelen voltam már bekapcsolni.
De azért köszi mindenkinek a segítséget.
Ami viszont érdekes, hogy a memtest lefutott hibátlanul, pedig ugye rossz volt egy modul... Bár végülis most már utólag mindegy, mert HP javította. Még egyszer köszi!

( lmisi | 2010. 03. 29., h – 13:16 )

A memtest kb. semennyit se ér, csak időpazarlás.
Mostanában raktam magamnak össze egy gépet, volt 2x1GByte ddr2 modul 800Mhz, de tudtam nem egészen korektek (Valami gel csodák).
De azért csak megpróbálkozik az ember...
Nos Ubuntu Luci telepítő cd 10 próbálkozásból ha egyszer eljutott a
grafikus felületig, utána gyors fagyás.
Próba 9.04-el, na ott végkép semmi.
Már arra gondoltam talán a ati4670 vga-nak nincs támogatása mivel

A csoda memtest 6 óra futtatás után se írt ki hibát, mégcsak le se fagyott.
De ekkor, elkezdtem csökkenteni a 800Mhz-lefelé talán 557-nél láss csodát szépen lefutott a telepítő. No ekkor kukáztam a ramokat és vettem 2x2Gigát
helyettük, azóta is teljesen stabil.