Fórumok
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ások
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