Random újraindulás

 ( bugos | 2011. február 28., hétfő - 12:48 )

Debian 6.0 rendszer 64bit, pár funkcióval (postfix+mysql, apache2, squid3, free-sa, soft raid), a gép megmagyarázhatatlan időközönként újraindul (mintha resetet nyomna az ember) van hogy naponta többször is, de van olyan nap amikor egyszer sem.

Mi lehet a gond? Táp csere volt, alaplap csere is. Esetleg proci? Winchester?

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

Túlmelegedés?
"Mintha reszetelnék" - fájl struktúra állapota - fsck?

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

kontaktos (haz) power switch, vagy esetleg torott a mikrokapcsolo benne.
nekem asztali gepen volt ilyennel szerencsem talalkozni - egy napig szenvedtem,
mire rajottem mitol indulgat ujra. ott a haz kabeleinek alaplaprol lehuzasa, majd
pwr-gnd egy csavarhuzo segitsegevel torteno zarasa vezetett a problema nyitjara. a
megoldast az ocska haz ivben torteno kivagasa jelentette.

Még nem találkoztam ilyennel, de attól még előfordulhat - egy próbát megér!

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

Itt 1x a kontakthibas reset-gomb volt a ludas; eltartott egy darabig rajonni...

szerintem nézd meg a kondikat az alaplapon

"Táp csere volt, alaplap csere is." - Uj alaplapnal csak nem puposak a kondik, bar valojaban lehet igazad, mert nem tudjuk, hogy uj/bolti alaplap kerult a gepbe, vagy csak egy _hasznalt_ masik...

Helló!

Lehet egy instabil áramszolgáltatás következménye is, pl. feszültség csökkenéskor, vagy pillanatnyi áramszünet esetén is. UPS van?

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

Ez egy 2010 decemberi szinte zsír új gép, természetesen szünetmentes is van. Ebben a hónapban kb. 3 napon volt újraindulása, volt amikor 2 alkalommal is, de általában csak egyszer. És semmi log bejegyzés vagy hasonló nyomravezető info. intel alaplap xeon-os proci 4 magos virtualisan 8 magos, 8 gb ecc ram, ház is valami minőségibb, 64bites 6.0-ás Debian van rajta, szoftveres RAID (tükör), postfix+mysql+imap, meg egy squid3 + sarg, és egy apache2 cacti+webmailhoz. Nemsoká cserélik a procit is. A winchesterek és a ház még a régi.

Épp tesztelem, nyúzom a gépet és ilyeneket látok néha:

Mar 17 07:56:24 mail kernel: [70868.761112] lowmem_reserve[]: 0 0 0 0
Mar 17 07:56:24 mail kernel: [70868.761541] Node 0 DMA: 2*4kB 2*8kB 4*16kB 3*32kB 3*64kB 3*128kB 1*256kB 1*512kB 2*1024kB 2*2048kB 2*4096kB = 15864kB
Mar 17 07:56:24 mail kernel: [70868.762595] Node 0 DMA32: 5708*4kB 1*8kB 0*16kB 1*32kB 0*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 23256kB
Mar 17 07:56:24 mail kernel: [70868.763652] Node 0 Normal: 408*4kB 11*8kB 1*16kB 0*32kB 1*64kB 1*128kB 0*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 2952kB
Mar 17 07:56:24 mail kernel: [70868.764709] 1877619 total pagecache pages
Mar 17 07:56:24 mail kernel: [70868.764870] 0 pages in swap cache
Mar 17 07:56:24 mail kernel: [70868.764974] Swap cache stats: add 0, delete 0, find 0/0
Mar 17 07:56:24 mail kernel: [70868.765106] Free swap = 7767988kB
Mar 17 07:56:24 mail kernel: [70868.765210] Total swap = 7767988kB
Mar 17 07:56:24 mail kernel: [70868.805930] 2097152 pages RAM
Mar 17 07:56:24 mail kernel: [70868.805933] 57870 pages reserved
Mar 17 07:56:24 mail kernel: [70868.805935] 1927662 pages shared
Mar 17 07:56:24 mail kernel: [70868.805937] 144403 pages non-shared
Mar 17 07:56:24 mail kernel: [70868.805940] SLUB: Unable to allocate memory on node -1 (gfp=0x20)
Mar 17 07:56:24 mail kernel: [70868.805945] cache: kmalloc-4096, object size: 4096, buffer size: 4096, default order: 3, min order: 0
Mar 17 07:56:24 mail kernel: [70868.805950] node 0: slabs: 1008, objs: 2009, free: 0
Mar 17 14:05:49 mail kernel: [93023.354980] swapper: page allocation failure. order:0, mode:0x4020
Mar 17 14:05:49 mail kernel: [93023.354987] Pid: 0, comm: swapper Not tainted 2.6.32-5-amd64 #1
Mar 17 14:05:49 mail kernel: [93023.355041] Call Trace:
Mar 17 14:05:49 mail kernel: [93023.355081] [] ? __alloc_pages_nodemask+0x592/0x5f4
Mar 17 14:05:49 mail kernel: [93023.355152] [] ? new_slab+0x5b/0x1ca
Mar 17 14:05:49 mail kernel: [93023.355203] [] ? __slab_alloc+0x1f0/0x39b
Mar 17 14:05:49 mail kernel: [93023.355257] [] ? __netdev_alloc_skb+0x29/0x45
Mar 17 14:05:49 mail kernel: [93023.355311] [] ? __alloc_skb+0x3e/0x15a
Mar 17 14:05:49 mail kernel: [93023.355364] [] ? __kmalloc_node_track_caller+0xbb/0x11b
Mar 17 14:05:49 mail kernel: [93023.355420] [] ? __netdev_alloc_skb+0x29/0x45
Mar 17 14:05:49 mail kernel: [93023.355474] [] ? __alloc_skb+0x69/0x15a
Mar 17 14:05:49 mail kernel: [93023.355528] [] ? swiotlb_map_page+0x0/0xc4
Mar 17 14:05:49 mail kernel: [93023.355581] [] ? __netdev_alloc_skb+0x29/0x45
Mar 17 14:05:49 mail kernel: [93023.355652] [] ? e1000_alloc_rx_buffers+0x85/0x1b3 [e1000e]
Mar 17 14:05:49 mail kernel: [93023.355742] [] ? e1000_clean_rx_irq+0x224/0x2bb [e1000e]
Mar 17 14:05:49 mail kernel: [93023.355805] [] ? e1000_clean+0x70/0x219 [e1000e]
Mar 17 14:05:49 mail kernel: [93023.355899] [] ? net_rx_action+0xae/0x1c9
Mar 17 14:05:49 mail kernel: [93023.355954] [] ? __do_softirq+0xdd/0x1a2
Mar 17 14:05:49 mail kernel: [93023.356012] [] ? e1000_intr_msi+0xf8/0x102 [e1000e]
Mar 17 14:05:49 mail kernel: [93023.356070] [] ? call_softirq+0x1c/0x30
Mar 17 14:05:49 mail kernel: [93023.356122] [] ? do_softirq+0x3f/0x7c
Mar 17 14:05:49 mail kernel: [93023.356175] [] ? irq_exit+0x36/0x76
Mar 17 14:05:49 mail kernel: [93023.356226] [] ? do_IRQ+0xa0/0xb6
Mar 17 14:05:49 mail kernel: [93023.356276] [] ? ret_from_intr+0x0/0x11
Mar 17 14:05:49 mail kernel: [93023.356326] [] ? acpi_idle_enter_bm+0x27d/0x2af [processor]
Mar 17 14:05:49 mail kernel: [93023.365028] [] ? acpi_idle_enter_bm+0x27d/0x2af [processor]
Mar 17 14:05:49 mail kernel: [93023.365115] [] ? acpi_idle_enter_bm+0x276/0x2af [processor]
Mar 17 14:05:49 mail kernel: [93023.365203] [] ? cpuidle_idle_call+0x94/0xee
Mar 17 14:05:49 mail kernel: [93023.365258] [] ? cpu_idle+0xa2/0xda

Próbáltam a swap-ot újra létrehozni, futott egy memteszt egész éjjel, de semmi hibára utaló jel nincs.
Reggeltöl estig FTP-n helyi hálóról másolok rá 1 TB adatot, de úgytűnik nem a winchesterekkel összefüggő a gond.
A Squid3 -ra tippelek, hogy attól van ez a csatt reset?!

Idézet:
futott egy memteszt egész éjjel

Attol meg lehet rossz... lattam mar egy par ilyet. Probalj ki egy egesz ejszakas (de inkabb egesz hetveges) kernelforditast, ha azt is kibirja, akkor valoszinuleg jo.

Esetleg memtest közben kicsit mozgasd meg a memóriát. Ha akkor hibát dob, akkor tisztítsd meg egy kicsit az érintkezőket.

Most nem akarok itt izé lenni, de ebben a logban nagyon az e1000 driver haldoklik szerintem. Persze lehet, hogy mittudomén és hülyeség.

Esetleg próbálj ki egy 2.6.33 alapú kernelt.

Linux 2.6.33 released:

Anton Blanchard (2):
      [...]
      e1000: Fix DMA mapping error handling on RX

Patch. A debian changelog-ban nem találtam meg. Csak egy tipp vaktában...

Eredetileg 2 db Kingston Value 4GB-s 1333-as memória van benne. Van otthon pár DDR3-as ramom, lehet cserélek párat és megnézem úgy is.

ha lehet a megoldást mindeképpen írd le majd:P

Nem egy gagyi gép ez a bosszantó. 2 db Xeon X3440 proci (8 mag összesen), intel server board alaplap, 2db 500GB WD5002ABYS RE3 winchester, 2 db 1TB Samsung HD103SJ winchester. 2db 4GB Kingston Value RAM

Láttam olyat hogy azonos random újraindulás történt egy hülyére tesztelt szerveren amin majdnem minden jó volt. Egyetlen dolgot kivéve, memtest86 a 12-ik!!!! körben ejtett 4 hibát és onnantól kezdve néha, intel szerver, kingston ram, stb. Egyéb ramnál találkoztam olyannal, hogy külön külön akármennyi teszt után is tökéletesek voltak, együtt szintén pár lefutott jó teszt után ejtett néhány hibát, amitől instabil volt a rendszer.

Én olyannal is, hogy egyben semmi hoba, külön-külön csak úgy szórták ;)

Igaz nem újraindulást, hanem ~1 napon belüli fagyást okozott egy beteg 4 magos AMD, kb. 3 nap alatt jutottunk el hozzá, RAM-alaplap-kontakthiba-fsck vonal végén. Nem meglepő módon kevesen tettek rá, hogy az lesz a hunyó :) (a táp azért versenyben volt gyanúban)

Most nézem a hibaüzenetet, az e1000 -et írja, ezek szerint lehet ethernet driver hiba lenne? Találkozott már valaki debian 6.0 alatt ilyesmivel (intel server board)?

Ezt a warning jellegű bejegyzést okozhatja driver (kernel), vagy még inkább mem. kezelési (kernel) bug is (vagy mindkettő együtt), de szerintem nem ez okozza a random újraindulást.

Ha most azt írod, hogy közvetlenül ez után a bejegyzés után jön a reset, akkor a kernel fejlődési iránya manapság nem igazán a stabilitás irányába mutat . ;-)

Érdemes lenne naplózni a hálózati terhelést, mert írod hogy csak időnként látsz ilyeneket.Lehet hogy csak magas terhelésnél jön elő. (?). De ez csak tipp.

És ha már tipp, akkor miért is ne lehetne megnövelni a

/proc/sys/vm/min_free_kbytes
értékét ?

De mégegyszer, szerintem ez a jelenség nem okoz random újraindulást, azt valami más válthatja ki. A hálózati terhelés naplózása mellett a sensors értéket is érdmemes lenne naplózni, különös tekintettel a feszültség értékekre. Ha van smart értéked, akkor abból a hőmérsékletet. Előbb utóbb csak lebukik a bűnös.

U.I: A cpuidle biztosan szükséges egy ilyen serveren ?

U.I 2: Ugye a server szünetmentesre van kötve ? Nehogy aztán kiderüljön, hogy a szomszéd valahol belefúrt a jól összekábelezett lakótelepen, és egy random jelentkező egészséges áramingadozás lett a végeredmény, vagy a kutya szétrágta a hosszabbító kábelét, vagy ugyanez a kábel a havi porszívózás közben kapott jókora maflást, estébé ? :D

U.I. 3.
ja most látom, azért hálózati terhelésed mondjuk van ;-):

Reggeltöl estig FTP-n helyi hálóról másolok rá 1 TB adatot

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

subscribe

(tetszik a nicked :) )

Mit értünk terhelés alatt? 1TB-ot másolok helyi hálón FTP-n keresztül, ha végzett újra és így tovább. Az eredeti helyen pedig egy Squid3 szolgálna ki kb. 50 gépet, valószínű akkor és ott jön néha a reset. Csak sajna itthon nem tudom a squidot csak max 3 kliensel terhelni. Azt gondolná az ember, hogy a 8 mag és a 8GB ram elégséges ilyenre. De ott a helyszínen naponta visszatérő a hirtelen reset, ami itthon sose jön elő, csak ez a kern.log bejegyzés utal esetleg erre a hibára.

Ez már nem tudomány, mágia!
Van néhány olyan kernel kapcsoló amit a problémás konfigurációknál szkás használni - bár ezek általában már az elején kibuknak. Viszont alogban amit küldtél van néhány acpi bejegyzés, mi lenne ha olyat próbálnál mint noacpi, noapi és vagy nolapic?

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

Énszerintem , ezt
/proc/sys/vm/min_free_kbytes az értéket
növeld meg. Végülis jókora böszme server.

Ennél sokkal rosszabb már nem lesz ;-).50% esélyed van, hogy segít, 50, hogy nem ;-)

Tippre eltűnik a memóriafoglalásos kernelbejegyzés, de nem szűnik meg a restart probléma.

Hardveres próbához pci=nomsi bootparaméter talán segít, meg a cpuidle kiszórása a kernelből... CONFIG_CPU_IDLE=n (!)

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.