Etch rejtélyes reboot

Fórumok

Hy all,

Egy hete levettem a szerverről a sarge-ot mivel már nem tudtam frissíteni.
Felkerül a legfrissebb etch.

Azóta rejtélyes módon néha reboot-ol a szerver. Van, hogy 1,5 napig elmegy van, hogy egymás után 2x-3x reboot-ol.

A terhelés sosincs 10% felett. A logokban semminek semmi nyoma. Csak azt látom, hogy minden üzemszerű volt és egyszer csak újraindul.

64bit Etch. AMD 3000+. 256 MB ram.

Igazából eddig a RAM-ra gyanakodtam mert bővíteni akartam és mindig rebbot volt. De már hülyének néznek a boltba, hogy a hatodik ramot viszem vissza.

Aki tud kérem, hogy segítsen!!

Hozzászólások

Egyrészt, sürgősen felejtsd el még az egy felkijáltójelet is, nemhogy a sokat, mert esetleg többen idegesek lesznek, joggal.
Másrészt, a sarge alatt lehet, hogy még nem volt a kernelben alapból beforgatva a Machine check exception, etch-en viszont már igen, ez szokott MCE-vel reboot-olni.

Így viszont, talán marad valami nyoma az incidensnek. Ráadásul, ha amennyiben ez az MCE dolog jól működik (nem működhet jól, hiszen valami nyomot kellene hagynia, már ha tényleg ez az ok) akkor előbb újraindítja a cuccot mintsem a "katasztrófa" bekövetkezne, így azt sem tudni mi is a baj.
Esetleg, nincs környezeti probléma? - túlmelegedés, rázkódás ...

* Én egy indián vagyok. Minden indián hazudik.

Ennek az MCE (gyors kereséssel valami multimédiás szépséget találtam Linux -ra) nevű dolognak nem kellene valamit "pottyantani" a syslog -ba?

Nekem most dőlt be egy kis célgépem ahol sajnos nem indult újra a cucc, ehelyett szépe lassan lekornyadt, eleinte még lehetett pingelni, de ssh -ni nem, aztán az sem. Reszet, után a syslogban semmi értelmezhetőt nem találtam. A fő gyanusítottam a disk, kicseréltem, és "próbapadon" futtatva, szimulált terheléssel napokig ment, így gondolom tényleg a disk volt a hunyó. Van valami más napló szerűség amit meg lehet nézni ilyenkor? Esetleg ha hálózaton keresztül (ppp, plip vagy hasonló) naplóznánk? Így talán kiderülhetne mi fittyed le.

* Én egy indián vagyok. Minden indián hazudik.

Ahan, 2.6.4-től kezdve nem jelennek meg az mce hisztik a kernel logban:

http://packages.debian.org/stable/admin/mcelog

"Starting with version 2.6.4, the Linux kernel for x86-64 no longer decodes and logs recoverable Machine Check Exception events to the kernel log on its own.

Instead, the MCE data is kept in a buffer which can be read from userpace via the /dev/mcelog device node.

You need this tool to collect and decode those events; it will log the decoded MCE events into /var/log/mcelog. Currently, mcelog can decode MCE from AMD K8 and Intel P4 (including Xeon) processors."

Érdemes lenne felrakni ezt is és nézegetni az mcelog-ot.

Gyors kérdés:
konzol switch-en van a szerver?

MCE log eddig nem segít. Azóta már 3x reboot volt, de az mcelog.log üres :(((

Akkor nem az mce a hunyó. Mi tud úgy elszállni, hogy semmi nyoma nem marad? Ez akár sw hiba is lehet, akár hw. Nincs más hátra dugj neki egy live CD -t nézd meg azzal mit csinál. Ha ezzel is leáll, akkor valószínűbb a hw hiba, ha nem akkor nézz körül hogy mi fut és kapcsolj ki mindent, ami nem feltétlenül kell.

* Én egy indián vagyok. Minden indián hazudik.

Reggel ismét reboot volt. Pedig senki sem dolgozott. Nem értem! :(

A logok persze üresek. Ami változott a gépen:

Korábban Sarge volt rajta 256 MB rammal 70GB SATA winyóval. Így tökéletesen üzemelt.

Most Etch a mem ua. HDD ua. + Samsung 750 GB SATA 32MB cache. Most szaraxik.

A kernel lehet hibás? A HDD ? Mért üresek a logok?

Senkinek sincs 5lete?

Na most talán sikerült valamit elkapni:
Egy könyvtár tartalmát szerettem volna másolni Mc-vel, de már másodperc után lefagyott a rendszer és a képernyőt tele írta:

Process kswapd0 (pid:175, threadinfo ffff81002f84e00, task ffff81002f60b000)

Stack:

Call tree:
[] jó pár sorba ilyesmiket írt.

És itt hivatkozott mbcache -re, kswapd, kthread

RIP [] isolate_lru_pages+0x76/0x1d9

És kész. Csak rezet gomb segített. Ez mond valakinek valamit?

Amúgy ami eddig is furcsa volt számomra:
738 MB RAM van most a gépbe. Ha végzek egy másolást akkor a szabad memória alig 4-5 MB.
Az 1GB swap -hoz viszont hozzá sem nyúl. Lehet itt valami bib?

Kernel frissítve 2.6.24-re

Ha van lehetoseg, csinalnek egy memtestet.
Meg jo lett volna egy kepernyokep a hibarol (mondjuk digitalis fenykepezovel). Ha esetleg elkapod megint, akkor csinalj, ha tudsz.
CONFIG_HIGHMEM van most a kernelben? Eddig is volt?

A dmesg-ben es a kernel logjaban valami? Bar ezen gondolom tul vagy mar.

Plusz amit feljebb ajanlottam:
If you want to log kernel messages over the network, enable this. See Documentation/networking/netconsole.txt for details.

Még mindig nincs megoldás.
Éjszaka kicsit átalakítottam a partíciós táblát mert a cfdisk nem indult el a /dev/sda6 miatt.
Ez volt amúgy a swap partíció. Most fut a cfdisk nem nyavajog azóta még nem sikerült kikényszerítenem a reboot-ot.
Megpróbáltam saját kernel-t fordítani, de a kernel fordítása közben még mindig fagy. (nem indul újra)

Hülyét kapok. Az okozhat gondot, hogy a root partíció (sda1) nem az első szektoron kezdődik?

fdisk /dev/sda -> (p) kimenete:

sda1 3673 - 9729 83 Linux (/) Boot
sda2 1 - 2433 83 Linux
sda3 2434 - 3672 5 Extend
sda5 2434 - 3406 83 Linux
sda6 3407 - 3606 82 Swap

Lehet a gond okozója, hogy a tábla nem a legszebb?

Nekem volt AMD 64 3000+ desktop, igaz nem server, és szundikkal sem omlott össze , meg nem rebootolt, bár a szundit (suspend_to_ram) nem volt egyszerű belőni.

A RAM/Swap aránya nem éppen a legszerencsésebb 256 MB/1024 swap?, de ez más kérdés. Elég ez egyáltalán ? Mennyit eszik a server? Látja a swapot a rendszer ? top kimenetben bentvan a swap ? Írtad hogy valamit itt kavartál.

A partíciós tábla nem oszt nem szoroz. Nekem pl. nincs hda2 :D. Egy régi partíció megszűnt, és egy régebbi megnőtt. A kutyát nem érdekli a partíciós tábla ha már bebootoltál.

A használt kernel configot (.config) esetleg feltölthetnéd egy dmesg kíséretében a pastebin.ca-ra vagy hasonlóra, hátha lesz itt valakinek ötlete. Mert így mindenki csak vaktában tapogatózik.

Én egy force ext(?) fájlrendszer ellenőrzést ráengednék, mert a sok fagyás miatt szerintem a fájlrendszer itt ott már odavan, és a journalt nem arra tervezték hogy állandó szabálytalan rebootolásoknál is állandóan üzemszerűen működjön.

Amíg nem áll helyre a rend egy tune2fs -c 1 (partíciót) léptetnék életbe az összes linuxos partíción.

A másik, hogy etch nél írták a relase infoban, hogy milyen extra fájlrendszer flag et célszerű rátenni a fájlrendszerre. debian.org/etch release doksi, már nem emléxem rá sajnos.

A harmadik, hogy smart al megnézném azért a vinyókat, ha lehetséges.

A negyedik, jó lenne tudni melyik "sata drivert" használod a kernelben , és melyik volt a sarge ban.

ha lehúzod a 750es vinyót akkor is fagy ?

Ha már vaktában lövünk, én kernel - SATA, vagy kernel - hálókártya problémára (kernel regresszió) tippelek, mert miért ne ? :)

-----------

r=1 vagyok, de ugatok...

Nah. a 256 MB ből lett 738 mega ram. ezek szerint saccra van 2 v.3 modulod / tippre 2 256+512) + integrált videókártya.

Gondolom a 2 modul nem tökegyforma. további vaktában lövöldözés (még mindig semmi config, semmi dmesg) :
modprobe eeeprom. és az lm sensors csomagban van a share-doc ban egy decode-dimms.pl (perl) szkript. Az megmondja,

Ha nem tökegyformák, kezd el lehúzni a modulokat egyesével, hogy mi történik. A végén csak egy maradhat. :D

A vaktában lődözés most az, hogy az általad használt BIOS mem beállítások (auto) nem felelnek meg valamelyik modulnak. Az auto nem tud mit kezdeni eltérő mem. modulokkal.

-----------

r=1 vagyok, de ugatok...

tune2fs -c 1 /dev/sda1
tune2fs -c 1 /dev/sda1

OK.OK

tune2fs -c 1 /dev/sda6 (ez a swap)

tune2fs: Bad magic number in super-block while trying to open /dev/sda6
Couldn't find valid filesystem superblock.

És azt sem értem még midig, hogy egy egyszerű másolásnál is mért lesz 4-5MB free memóriám a 730MB-ből. Majd, ha végetért a művelet 200-300MB lesz free.

Kikapcsoltam a swap partíciót és létrehoztam egy swap fájlt.

Most először sikeresen lefordult a kernel. Másodszor ismét a fenti hibával megállt a gép DE NEM fagyott le. Megy tovább! ??

Szólt a kernel, hogy javította a hibát, de szükséges az újraindítás.

?????

most 1db 512MB RAM van benne és 1GB SWAP file.

próbáltam ubuntu server-t telepíteni. nem sikerült.
Próbáltam más HDD-re más Rammal nem sikerült. Mindig ua. a hiba. Vagy lefagy, vagy reboot, vagy a fent látható kép fogad. :((((

Holnap reggel ennek a szervernek üzemelnie kell.

Igen, megnézném, hogy a procihűtő rendesen a helyén van-e.

Ha felmegy a load, akkor fekszik meg? SATA kábeleket cserélgetted? Próbáltad másik alaplapi csatlakozóra dugni?

Esetleg meg kéne hajtnai valami benchmark programmal (pl. bonnie++), mint Singer úr, hogy tényleg a diszk i/o növekedése fekteti-e meg.

Külön kipróbálnám a CPU-t is valami megfelelő progival hajtva. Pl. az nbench egész jó erre a célra: http://www.tux.org/~mayer/linux/bmark.html

<OFF>

Erről az egészről a klasszikus zsidó vicc jut eszembe.

Kohn elpanaszolja a rabbinak, hogy döglenek a libái.
- Mivel eteted őket?
- Szemes kukoricával.
- Az a baj. Etesd ezután darával!
Kohn egy hét múlva ismét panaszkodik, hogy még mindig döglenek a libái, pedig darával eteti őket.
- Mert szamár vagy! - mondja a rabbi. - Zabbal etesd őket!
Pár nap múlva Kohn megint siránkozik, hogy hiába eteti zabbal a libáit, mégis pusztulnak.
- Ostoba fajankó vagy, miért nem árpával eteted őket?!
Másnap megint megy Kohn:
- Rabelében, hiába próbálkoztam az árpával, megdöglött az utolsó libám is!
- Most már egy libád sincs?
- Egyetlen egy se.
- Kár. Pedig még annyi jó ötletem lett volna...

</OFF>

Mivel nem volt már időm a hiba keresgélésére így alaplap+cpu+mem csere lett a vége.
Remélem nem jelentkezik újra a hiba.