Sziasztok!
Némi segítségre lenne szükségem azt illetően, hogy egy adott szervergépen hogyan és mint lehetne behatárolni egy nehezen felderíthető hibát, ami kernel oopsokat és a folyamatok szépen, sorban történő elhalását eredményezi: először mysql (igen hamar, akár rögtön, indításkor), aztán named, majd megint más, általában hasonló sorrendben.
Memtest hibátlanul lefutott, live-cd-ről az fsck minden partícióra hibátlanul lefutott, ugyancsak live-cd-ről indított "cat /dev/sd[a,b,..] > /dev/null" parancsra szintén nem panaszkodott a rendszer.
Rootkit vizsgálat még nem volt, de - nem mintha láttam volna már rootkites gépet - a tünetek alapján úgy sejtem, hogy nem ilyesmi okozza.
Konfiguráció:
- Broadcom HT1000 csipszet
- AMD Opteron 2212, 2ghz
- 2GB DDR2 Kingston ECC RAM
- 2db Samsung HD501LJ merevlemez, szoftveres raid1-ben
- Debian Etch
- JFS fájlrendszer minden partíción
Van valakinek ötlete, merre tovább? Cserebere, hogy próbáljuk ki más cuccokkal, darabonként cseréljünk ki mindent stb., nehezen vagy egyáltalán nem oldható meg. Minden olyan Samsung vinyóval rossz tapasztalatom van, aminek valaha a közelébe kerültem, ami nagyobb 80GB-nál. Másnak is esetleg? Furcsállom, hogy rendesen lefutott a memtest - igaz, csak egyszer -, mert tipikusan memória-hibának tűnik a dolog. Tud valaki olyanról, hogy az ECC-nek köszönhetően egy memtest lefut, "élesben" viszont előjön egy hiba?
Tipikusan ilyeneket látni a dmesg-ben:
Unable to handle kernel paging request at 00002aaac7083000 RIP:
[]
PGD 1994f067 PUD 19da9067 PMD 0
Oops: 0002 [1] SMP
CPU 0
... regiszterek tartalma...
Process [folyamat neve] (pid: 3459, threadinfo ffff810018d1a000, task ffff810029453080)
Stack: 0000000000000000 ffffffff8020bce8 00000000402295e0 00002aaac543f910
ffff810028db8ec0 ffffffff88035000 00002aaac543f910 ffffffff88035000
0000000028db8ec0 00002aaac70835dc ffff81003ea802c0 00002aaac7083000
Call Trace:
[] _atomic_dec_and_lock+0x39/0x57
[] system_call+0x7e/0x83
A géppel közel egy évig semmi gond sem volt. (Más: az ilyen témákat hova kell tenni itt, a fúrumon belül? Még ez tűnt a leginkább testhezállónak.)
Tud esetleg valaki egy jó, diagnosztikai programot, ami jó eséllyel behatárolja a hibát?
Előre is köszi minden építő hozzászólást!
Chreex
- 1410 megtekintés
Hozzászólások
próbáltad már nulláról újrarakni 64 bites lennyvel?
nálam a sorrend:
- melegedés, vagyis hűtés ellenőrzése
- memória cserebere
- táp (esetleg ha volt, szünetmentes mellőzése egy időre)
igazi gyilkolászást több, párhuzamos kernelfordítással lehet csinálni, sok jobbal.
- A hozzászóláshoz be kell jelentkezni
+1
Pedig viszonylag 1xű a játék, ha reprodukálható a hiba akkor alkatrész cserélgetéssel be lehet határolni mi okozhatja. Ez megtörtént már?
Szerk. ja hogy nem (most látom). Pedig kellene...
- A hozzászóláshoz be kell jelentkezni
+1 melegedés ( cpu, chipset ) portalanítás majd újraindítás.
--
üdv: virtualm
- A hozzászóláshoz be kell jelentkezni
"Tud valaki olyanról, hogy az ECC-nek köszönhetően egy memtest lefut, "élesben" viszont előjön egy hiba? "
Az ECC-tol fuggetlenul, de mar lattunk ilyet.
Mikor volt utoljara kernel upgrade?
Azokat az oops-okat lathatnank egeszben (mondjuk az utolso >3 db-ot)?
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Marmint ugy ertettem, hogy kozottuk egy reboot-al.
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
Képzeld el ugyanezt háromszor, egymás után, némileg eltérő időbélyegekkel. :) Tényleg szinte bitre megegyeznek.
Mindenkinek köszi az ötleteket, asszem, marad az alkatrészcsere - muszáj lesz megoldani.
- A hozzászóláshoz be kell jelentkezni
Akkor ez nem igazan tunik hw-hibanak.
Masold ki livecd-rol bootolva a kernel image-t + a kernel modulokat, es hasonlitsd ossze egy ugyanilyen szuz debianeval, meg esetleg probald ki ujonnan forditott vanilla kernellel.
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
Én is jártam már úgy, hogy adott gép viszonylag ritkán, de rendszeresen hibajelenségeket produkált, általában 1-2 hét alatt megállt. Memtest nem volt hosszan futtatva, de néhány kör alatt semmi hibát nem jelzett...
Ugyanakkor RAM-cserével már fél éve nincs vele gond.
Ettől függetlenül mindenekelőtt melegedés (pl. CPU /esetleg hővezető paszta csere/, ventik /kosz, fordulatszám/, chipset hűtés), táp ellenőrzése nem árt.
- A hozzászóláshoz be kell jelentkezni
nekem 870 napos uptime-t vitt el egy memória hiba, brühühü
memória csere óta jól megy...
- A hozzászóláshoz be kell jelentkezni
Cserebere helyett - ha van rá fiskális keret - először csinálj másikat, utána ráérsz ezt mosdatni.
Nekem gyanús volt az örökölt szerverem, ezért először összeraktam egy működő másikat. Csak aztán szöszöltem a publikus forgalomból kivont régin; mert muszály rájönni, hogy mi a szentszar van, - a probléma ettől még probléma maradt - de így nyugisabb a tetvészkedés mint élesben.
- A hozzászóláshoz be kell jelentkezni
Valamilyen frissites vagy SW telepites nem elozte meg ezeket a hibakat? Volt-e rendszer frissites a hiba keletkezese elott? Single mode-ban is produkalja a tuneteket? Top mit mond mi fut? Dmesg? Logok?
Nekem a debian az intel atom-os alaplapomon szorakozott idonkent el-el szallt magatol. Mint kesobb kiderult, az ACPI kezelessel volt a problemaja, amit azota sem tudtam debian alatt beuzemelni. Proba keppen egy Ubuntu servert tettem ra, azzal szepen megy azota is. Esetleg probalj meg masik OS-t tenni ra (Akar live CD-rol is.), lehet egy bug valamelyik driverben.
--
TH
- A hozzászóláshoz be kell jelentkezni