Centos kernel panic, a dátum átáll 2012-re, mi okozhatja?

 ( yoursoft | 2011. július 1., péntek - 12:54 )

Van 3 szerverünk. Időnként kernel panic-al leállnak a gépek. Boot után 2012-re állnak.
Pl. ma 2012 jun 29 Fri volt, az óra jól járt.

Nincs ntp a gépeken.

Vajon valami hardver hiba lesz? Ha pl. a dátum átáll a kernel közreműködése nélkül hirtelen 1 évvel későbbre, az okozhat kernel panic-ot?

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

teszteli a világvége utáni állapotot... :-)

De az még előtte van!
ON:
Mind a három szerver ugyanúgy? Eléggé gyanús ha igen.

Mid három blade-t együtt kaptuk. Ugyanaz a kiépítés. És már mindegyiken előjött.

bios típus, verzió?
------------------------------------
Az 1337-es számú linuxfanboy

Sőt, géptípus, gyártó?

van konkrét oka, hogy nem használtok ntpt?

Még nincs éles státuszban.

A dátum hiba már megvan.
Megnéztem egy 4. szerverünket ott is 2012 volt a dátum a hardver óra szerint.
Csak sync-elni kellett a Linux óráját a hardver órával (hwclock --systohc).
Ezért volt, hogy boot után az óra 2012-re állt.

A kernel panic-ot viszont még nem értem. Semmi sem marad a logban.

kdumpot rakj fel, utána okosabb leszel.

-
Debian Squeeze

Sajnos a kdump felrakása a rendszergazdán múlik. Neki meg nincs ideje erre. Ráadásul standard csomagot szeretne mindenből.

Egyébként HP ProLiant BL465c G7 típusú gépek.

Találtunk egy állapotot, amikor fixen meg lehet fektetni az sql-eket(VPN-en keresztül, pgadmin postgresql-hez 10 kapcsolódásból 1 kernel panic, de csak 1 gépről). Ez viszont nem magyarázza a web szerver megfekvéseit.

A képernyő panic esetén nem görgethető. Így az oka sem látszik a rendszergazda szerint.

Sajnos a kdump felrakása a rendszergazdán múlik. Neki meg nincs ideje erre.
-neked mint ügyfélnek, meg kell győznöd arról hogy ha megfekszik a gép, az neki sem jó.
(Ha ma beszéltél vele, akkor a don't touch the system on Friday aranyszabályt követte, próbáld meg hétfőn)

Ráadásul standard csomagot szeretne mindenből.
-van belőle, ezt tudnia kell. Nekünk anno a RedHat-es fiúk azt mondták, amíg nincs memory dump, nincs további support. Egész egyszerűen szükséges volt, így az ügyfél beleegyezett a telepítésbe.

"Egyébként HP ProLiant BL465c G7 típusú gépek"
Akkor ők egy dobozba vannak zárva? Nézd meg az "enclosure" óráját, ha jól emlékszem akkor a bayek syncelnek az enclosure órájával mikor reboot van. Valószínüsítem hogy itt a probléma.

Van egy sanda gyanúm, hogy az enclosure-hez is csak a rendszergazda fér hozzá, ezesetben nyaggatni kell.

"A képernyő panic esetén nem görgethető. Így az oka sem látszik a rendszergazda szerint."
Ez emlékezted egy JPG-s bugreportra. :D
De komolyra fordítva a szót. Pontosan azért kell a crashdump mert nem látszik, ezt neki tudnia kell.

-
Debian Squeeze

Praktikus volna mindent (OA, iLO-k, serverek) legalább egymáshoz szinkronizálni ntp-vel, de mégjobb ha valódi time serverhez.

Azt ntp-s szinkron úgy látom már megy :-)

Köszi a választ.

A rendszergazdával beszéltem. Mondtam, hogy van centos csomagja. A telepítését és beállításait meg is találtam.
Viszont a rendszergazda azt mondta, hogy szerinte csak memória dumpot csinál, azt meg próbáljam kianalizálni, ha tudom.

Találtam néhány linket a crash éskdump használatáról ezt most átküldtem Neki.

"Találtam néhány linket a crash éskdump használatáról ezt most átküldtem Neki."

A szakszerű telepítés utáni configra figyelni kell, ha emlékeim nem csalnak a primary partícióra fogja kiírni. Kellemetlen lenne ha megtelne a /

"a rendszergazda azt mondta, hogy szerinte csak memória dumpot csinál, azt meg próbáljam kianalizálni, ha tudom."

Ebben nem tévedett, de erre van a crash.

-
Debian Squeeze

Ha meguntad a szopást a nyomorék linuxos gyerekkel, dobj egy mailt.

+1
------------------------------------
Az 1337-es számú linuxfanboy

Szerintem csak ideje nincs. Lehet, hogy túl sok szervert bíztak rá.

A skill, a szerverek szama, es a szabadido egyenesen aranyos.

A kernel dump-ra ezt nyomja a crash:

KERNEL: /usr/lib/debug/lib/modules/2.6.18-238.9.1.el5debug/vmlinux
DUMPFILE: /var/crash/2011-07-11-07:21/vmcore
CPUS: 8
DATE: Mon Jul 11 07:19:40 2011
UPTIME: 1 days, 17:02:24
LOAD AVERAGE: 0.12, 0.06, 0.06
TASKS: 222
NODENAME: reflex4
RELEASE: 2.6.18-238.12.1.el5debug
VERSION: #1 SMP Tue May 31 14:44:25 EDT 2011
MACHINE: x86_64 (2400 Mhz)
MEMORY: 7.8 GB
PANIC: crash: invalid size request: -2144571075 type: "log_buf contents"

#0 0xffffffff8006fd64 in raw_safe_halt () at include/asm/irqflags.h:119
119 __asm__ __volatile__("sti; hlt" : : : "memory")

Ti tudtok valami okosságot ebből kitalálni?

uptime helyes?
------------------------------------
Az 1337-es számú linuxfanboy

Szerintem igen. Ma reggel akasztottuk ki, előtte valamikor szombaton. Majd úgy lett újraindítva.

KERNEL: /usr/lib/debug/lib/modules/2.6.18-238.9.1.el5debug/vmlinux

A crash szerint egy többéves kernelt használsz, amelyre fölnyomtak többszáz patchet pár hónapja... [Ejnye, de ráérnek!]

Version : 2.6.18
Vendor : Red Hat, Inc_
Release : 238.9.1.el5
Date : 2011-03-18 18:23:38

Esetleg volna lehetőséged friss kernellel is tesztelni ezt a crasht?

Tudtommal ez a hivatalos kernel a CentOs 5.x-ben.

Most a rendszergazda arra jutott, hogy kicsi volt a max. csomag méret. Ezt fölemelte arra ami a régi szerveren volt.
Nemsokára teszteljük.

És ha továbbgondolom (remélem nem gondolom nagyon mellé), ez a kernel még a
Red Hat Enterprise Linux 5-höz készült: az alapul a 2.6.18-on...

Oh, ott a pont! :) Mármint nálad, yoursoft.

igen, valaki nem ismeri a size_t-t

--
NetBSD - Simplicity is prerequisite for reliability

Egy kicsit bővebben ki tudnád fejteni?
Mihez kapcsolódik ez, hálózat, fájl kezelés, memória kezelés?

No a csomagméret állítás nem jött be. Még nézelődünk.

Ok, nem jutunk előbbre. Másik distro-t telepítünk.

Úgyis most jött ki a CentOS 6:D