I sintomi sembrano quelli di un kernel panic con tanto
di backtrace. Ovviamente la tastiera ᅵ fuori uso per
cui non posso scorrere verticalmente lo schermo per
leggere completamente i messaggi di errore.
Stranamente, perᅵ, non vedo nemmeno scritte tipo
"kernel panic" o "oops", vedo solo il backtrace.
Esiste un modo per salvare questa vagonata di messaggi
su disco? Altrimenti mi risulta impossibile capire cosa
sta generando cosa, dato che la parte interessante
probabilmente ᅵ ad inizio schermata.
L'unica cosa che ho fatto in tempo a leggere sono errori
tipo: "i386" che ovviamente detti cosᅵ non danno alcun
contributo alla discussione.
--
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito ᅵ di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.
E non vengono salvati nel log?
Davide
no, zero.
Ieri ho avuto lo stesso problema (ma avevo la
console 'in blanking' ovvero non vedevo nulla
a video) ed i log, tutti (syslog messages ed altri)
non dicevano nulla.
--
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito � di fare il possibile per la
Mooolto strano. E poco prima del crash non resta niente di 'anomalo'
nei log? Sicuro che i messaggi del kernel siano anche inviati al log (/
etc/syslog.conf)?
Perche' se no, la vedo dura a salvare tali messaggi... A meno che non
sia un errore causato da una qualche applicazione che _poi_ provoca il
crash della macchina.
Davide
Di solito i messaggi del kernel vanno in /var/log/syslog e lo
vedo dal fatto che hanno "kernel:" come prefisso.
Adesso ho attivato anche "kernel.* -/var/log/kernel.log" così loggo
da ambo le parti (non serve a niente, ma non si sa mai).
Durante i crash no noto nulla di anomalo. La macchina va in coma e
basta, non fa altro. Riavvio brutalmente ed il primo log che trovo
è quello di caricamento del kernel. In nessun log, tra la riga di
caricamento kernel e quella precedente a macchina ancora viva, non
ho nulla.
Guarda tu stesso:
Nov 3 22:52:20 gss last message repeated 3 times
Nov 4 10:11:34 gss kernel: ACPI Error (tbxfroot-0219): A valid RSDP was
not found [20090320]
Nov 4 10:11:35 gss kernel: Zone PFN ranges:
Nov 4 10:11:35 gss kernel: DMA 0x00000010 -> 0x00001000
Nov 4 10:11:35 gss kernel: Normal 0x00001000 -> 0x000377fe
Nov 4 10:11:35 gss kernel: HighMem 0x000377fe -> 0x0003f800
( A dire il vero, oggi, e solo oggi, ho notato un mucchio di porcherie
in stile "binario" loggate subito prima del reboot forzato. Potrebbe
essere un dump, ma è illeggibile, sono porcate di 'sto tipo:
�� 61�J71�J�f�J3 �E�� `g�^���i�YZ
��j� ��dJ��dJq 3<.hII=� H�B^ u8�I���Z� �� �� 71�J81�Jo��J
ma non viene loggato sempre...)
> Perche' se no, la vedo dura a salvare tali messaggi... A meno che non
> sia un errore causato da una qualche applicazione che _poi_ provoca il
> crash della macchina.
Tutto può essere, ma l'eventuale errore di qualche applicazione è
scritto "in alto", ovvero dove l'errore ha inizio, ed io ho solo "il
basso", in pratica vedo solo il risultato (che è l'unica cosa di cui
non mi importa, lo vedo da solo che si è impanicato o simile)
Per la cronaca sto ricompilando il kernel, non si sa mai che sia un
qualche baco con tanto di verme dentro.
--
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
> Davide Bianchi ha scritto:
>> E non vengono salvati nel log?
>
> no, zero.
>
> Ieri ho avuto lo stesso problema (ma avevo la
> console 'in blanking' ovvero non vedevo nulla
> a video) ed i log, tutti (syslog messages ed altri)
> non dicevano nulla.
Non riesco a controllare da qui, ma forse c'e' un qualche SisRq+qualcosa che
potrebbe darti maggiori informazioni (SysRq+t forse, ma potrei sbagliarmi).
Si', ottimo.. ma sarebbe bello vedere cosa c'e' PRIMA delle 22.52.
Davide
Davide
Nulla di interessante, ecco l'intero syslog tra due reboot forzati:
Ripeto che il "dump" che si nota, l'ho visto oggi per la prima volta,
in tutti gli altri reboot non ho nemmeno quello ma solo un taglio
netto del log.
--
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito � di fare il possibile per la
bhe'... quella spataffiata di roba simil-binaria mi fa pensare ad un
qualche baco nel sistema che ti scarica monnezza in syslog... e
considerando che la macchina sembra essere un firewall/gateway,
potrebbe essere qualcuno che prova a fare qualche cosa di poco pulito
magari?
Ma lo ha cominciato a fare da ora o... come e' la storia?
Davide
in /etc/default/bootlogd
inserire: BOOTLOGD_ENABLE=Yes
ma il kernel deve partire.......
Pu� essere, ma come posso fare la diagnosi?
Sarebbe tutto pi� semplice se fosse possibile salvare
il dump che vedo a video. Li, a video, c'� la soluzione.
magari � scritto che il kernel schiatta con un modulo
del piffero che nemmeno mi serve.
Ma non riesco ad andare in su con lo schermo e la cosa
mi fa incazzare non poco, � come avere la soluzione
tra le mani senza poterla leggere per intero.
> Ma lo ha cominciato a fare da ora o... come e' la storia?
Lo ha fatto da sempre.
Prima con un hardware differente. Abbiamo sostituito ogni
sorta di componenti (come ho gi� detto, avevo il terminale
in blanking quindi non vedevo gli errori), poi ho sostituito
l'intera macchina. Quella attuale ha cpu differenti, ram differente
e chipset delle nic differenti dalla vecchia. In pratica cambia
tutta l'architettura, grossomodo.
Eppure mi collassa saltuariamente, in orari 'randomici'.
Ho tenuto entrambe le macchine da me per almeno 20 giorni
l'una senza alcun problema. Per cui, sembra una incompatibilit�
tra il software installato sulla macchina e qualche cosa presente
nella rete del cliente, perch� se fosse un problema circoscritto
all'hardware, schiatterebbe anche da me.
Devo anche ammettere che c'� un ponte radio che collega una seconda
sede, con un secondo firewall gemello (gemello della macchina
precedente, non di quella attuale) con stesso kernel, stesso hardware
stessi switch, stessi cavi.
C'� una VPN che collega le due sedi (o megli, c'� una VPN con sopra 5-6
vlan) e le mette in bridge, per cui quello che succede da un lato
arriva anche nell'altro.
sede_b->firewall_b-->wifi-->firewall_a-->sede_a
il firewall_a poi � connesso ad internet e ad altre reti, tutte
in bridge con varie vlan presenti nel lato_b.
(per farla breve, in sede_a ho delle nic fisiche in bridge con le
vlan della sede_b veicolate tramite una vpn)
Ma io non devo registrare i messaggi al boot....
Quelli li vedo, io devo registrare l'impanicamento
o robe simili del kernel a macchina viva e vegeta.
Loggando i messaggi del firewall? Perche' da quello che si vede nel
tuo log c'e' poco e niente...
> Sarebbe tutto più semplice se fosse possibile salvare
> il dump che vedo a video. Li, a video, c'è la soluzione.
Dirottare la console su un file? Avere una console "seriale" che in
realta' salva in un file?
> Lo ha fatto da sempre.
> Prima con un hardware differente.
E allora non puo' essere un problema hardware, deve essere qualche
cosa nel software.
Davide
Ottimo, come si pu� fare a loggare la console su un file?
Ed in tal caso, mi vengono loggati anche eventuali oops e panic?
Comunque, l'ha appena rifatto, 'sto giro ho fatto una foto
allo schermo, vedo un sacco di scritte ma prese singolarmente
non mi permettono di diagnosticare il problema.
Il trace termina con "i386_start_kernel+0x51/0x90"
Nei log, questa volta, non ho il binario, ma in un modo
o nell'altro c'� sempre l'errore dhcp ed ho notato che
il server collassa (anche a distanza di svariate ore) sempre
dopo gli errori dhcp. Anche nei log postati in precedenza,
gli ultimi errori erano quelli inerenti il dhcp, proprio come
questi qu� sotto, ma magari si erano verificati 6 ore prima
del crash.
Nov 4 13:16:56 gss dhcpd: if xxxxxxxx.yyyy.lan IN A rrset doesn't exist
add xxxxxxxx.yyyy.lan 1800 IN A 192.168.1.147: timed out.
Nov 4 13:19:25 gss dhcpd: if xxxxxxxx.yyyy.lan IN A rrset doesn't exist
add xxxxxxxx.yyyy.lan 1800 IN A 192.168.1.147: timed out.
Nov 4 13:49:27 gss dhcpd: if xxxxxxxx.yyyy.lan IN A rrset doesn't exist
add xxxxxxxx.yyyy.lan 1800 IN A 192.168.1.147: timed out.
Nov 4 14:19:30 gss dhcpd: if xxxxxxxx.yyyy.lan IN A rrset doesn't exist
add xxxxxxxx.yyyy.lan 1800 IN A 192.168.1.147: timed out.
Nov 4 14:33:19 gss dhcpd: if xxxxxxxx.yyyy.lan IN A rrset doesn't exist
add xxxxxxxx.yyyy.lan 1800 IN A 192.168.1.147: timed out.
Nov 4 15:24:54 gss kernel: ACPI Error (tbxfroot-0219): A valid RSDP was
not found [20090320]
Nov 4 15:24:54 gss kernel: Zone PFN ranges:
Nov 4 15:24:54 gss kernel: DMA 0x00000010 -> 0x00001000
Nov 4 15:24:54 gss kernel: Normal 0x00001000 -> 0x000377fe
Nov 4 15:24:54 gss kernel: HighMem 0x000377fe -> 0x0003f800
Nov 4 15:24:54 gss kernel: Movable zone start PFN for each node
Se riesco a terminare la compilazione...
Mi schiatta la macchina prima di portarla a termine.
Heee... Bella domanda, credo seguendo lo stesso metodo che si usa per
reindirizzare la console su seriale ma specificando un file invece
della seriale...
> o nell'altro c'è sempre l'errore dhcp ed ho notato che
> il server collassa (anche a distanza di svariate ore) sempre
> dopo gli errori dhcp.
Baco nel driver della scheda di rete?
> Nov 4 13:16:56 gss dhcpd: if xxxxxxxx.yyyy.lan IN A rrset doesn't exist
Pare che cerchi di aggiornare il DNS. Magari configurarlo in modo da
non farlo?
Davide
Compila su una macchina diversa!
Davide
Non avrai mica un compilatore su un firewall?
Non so, non ho mai provato a salvare su file, non sapevo
nemmeno fosse possibile e googolando non ho trovato molto.
Comunque sia devo riavviare. Al primo panic lo faccio.
Non ha molto senso riavviare quando tutto funziona, ci pensa
gi� per conto suo a richiedere un reboot :-)
> Baco nel driver della scheda di rete?
tutto pu� essere, ma sono realtek comunissime, per cui potrei
quasi escluderlo a priori, sarebbe impossibile che nessun altro
se ne sia mai accordo considerato il chipset e la sua diffusione.
> Pare che cerchi di aggiornare il DNS. Magari configurarlo in modo da
> non farlo?
Si l'ho fatto 1 ora fa circa. Stiamo a vedere se regge.
lo sto facendo, per chi mi hai preso? :)
Di norma no, l'ho installato oggi per venir a
capo da sto problema.
> Ho una macchina che senza apparente motivo si freeza scrivendo vagonate
> di roba a video.
netconsole
Già lo conoscevo, già ho provato ad usarlo.
E' da stamattina che ci provo, ma non mi logga un
piffero. (devo loggare in remoto, non nella stessa
LAN).
Seguendo le istruzioni, bisognerebbe mettere il mac-address
del gateway, ma niente, non logga.
--
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
Bon, ora va.
Aspettiamo......
Non è servito a niente.
Si è freezata di nuovo e netconsole mi ha inviato
solo l'equivalente del syslog sulla macchina remota.
Ho notato però una cosa strana, che non avevo mai
avuto prima: il crash è preceduto dal dump di intere
sezioni di un sito internet, compreso tutte le immagini
e gli header HTTP. Molto strano.
> Ho notato però una cosa strana, che non avevo mai avuto prima: il crash
> è preceduto dal dump di intere sezioni di un sito internet, compreso
> tutte le immagini e gli header HTTP. Molto strano.
Non capisco. Dump de che e dove ?
Non sei l'unico a non capire.
Ho, nel syslog (e poi dovrò capire come c'è finito li) un
dump di alcune transazioni HTTP.
Ad esempio:
HTTP/1.1 200 OK
Date: Mon, 18 Apr 2005 16:38:00 GMT
Server: Apache/1.3.27 (Unix)
Last-Modified: Thu, 01 Jul 2004 01:16:05 GMT
ETag: "158e008c-182c-40e365d5"
Accept-Ranges: bytes
Content-Length: 6188
Connection: close
Content-Type: text/html
<html>
<head>
<title>...
(testo preso da google, non è quello effettivo del
cliente, ma ai fini del discorso non cambia nulla)
come cacchio c'è finito un dump di una transazione HTTP
dentro il syslog? No, non sono cretino, ho controllato 5
volte da quanto ero incredulo.
C'è squid su quella macchina, ma NON logga tramite syslog
per cui nemmeno dire che abbia fatto casino con la configurazione
di /etc/syslog.conf, dato che squid logga per i fatti suoi.
Subito dopo svariate sessioni http c'è stato il crash.
Può essere un dump fatto da una scheda di rete?
Qualche cosa mi fa pensare che il dump era diretto verso un device di
rete, il kernel si e' impallato e la memoria e' stata dirottata verso
lo schermo.
Ora, potrebbe essere il sintomo di qualcuno che cerca di utilizzare un
qualche exploit (kernel bug) per ottenere accesso al sistema o
potrebbe essere un kernel bug e basta.
Davide
Dimenticavo di dire che:
1) il dump l'ho ricevuto via netconsole, la macchina ha crashato e nel
server preposto a ricevere i log della console ho visto questo dump
2) il kernel � l'ultimo, ricompilato ieri pomeriggio.
Mi fa strano che ci sia lo stesso bug del kernel in almeno 4
versioni differenti (e non tanto differenti a livello di patch-level
ma proprio di versione: 2.6.28 - 2.6.30, ...)
> Mi fa strano che ci sia lo stesso bug del kernel in almeno 4
> versioni differenti (e non tanto differenti a livello di patch-level
> ma proprio di versione: 2.6.28 - 2.6.30, ...)
http://www.theregister.co.uk/2009/11/03/linux_kernel_vulnerability/
E comunque, potrebbe benissimo essere un bug in uno dei driver che non
sono cambiati.
Davide
Se hai ricompilato il 2.6.31.5 e ti fa lo stesso scherzo non ti rimane
che
una via da intraprendere. Raccogli i tuoi lamenti e vai da quelle
lontane genti
cogli occhi piu` grandi e le orecchie piu` lunghe, che scrivono in una
lingua straniera.
Per parlare con loro invia una mail a majo...@vger.kernel.org
e metti nel corpo del messaggio: subscribe linux-kernel.
Andrea
> On 5 Nov, 15:02, Gandalf Corvotempesta <gandalf.corvotempe...@gmail.com>
> wrote:
>> Il 05/11/2009 14:54, Davide Bianchi ha scritto:
>>
>> > Ora, potrebbe essere il sintomo di qualcuno che cerca di utilizzare
>> > un qualche exploit (kernel bug) per ottenere accesso al sistema o
>> > potrebbe essere un kernel bug e basta.
che gli ultimi kernel siano bucabili non è una novirà.
Ma se il kernel ha scritto quella roba, secondo me è brutto.
Anche io consiglio una mail a LKML che non fa mai male...
(una volta un http server embedded nel kernel, non è che è quello ?
chissà se esiste ancora)
Da lunedì in poi gli scrivo.
Oggi ho avuto ben altri problemi, domani rimetto in funzione
la netconsole e lunedì faccio una diagnosi.
> (una volta un http server embedded nel kernel, non è che è quello ?
> chissà se esiste ancora)
Non mi pare di aver attivato un qualcosa di simile.
Non saprei nemmeno che farmene, per cui non l'ho attivato :)
Beh, e allora!?
Non ho ancora avuto modo di attivare la netconsole :)
--
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito � di fare il possibile per la
Allora, ho staccato squid.
E' proprio spento, ed iptables non
natta pi� verso la 3128.
Non si � pi� bloccato, fino ad ora.
Questo potrebbe spiegare anche il dump
di una pagina HTML sul syslog, come avevo
scritto tempo fa.
Ma come � possibile che un proxy user-space faccia
impanicare un kernel per intero?
Mi sembra 'na cagata stile windows che una applicazione
generi un kernel panic.
--
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito � di fare il possibile per la
Kernel bug?
Su Linux Kernel ml sarebbero felici di saperne di piu`,
tu potendo riferire (ovvero avendone il tempo e/o riuscendo a
trovarlo).
Andrea
Io dico che se invece di implementare a tutti i
costi il driver di $solcazzo o come supportare
la features all'ultimo grido, fixassero i bug
attuali (ed ultimamente ne girano pi� di una volta)
sarebbe meglio.
Non � mica windows dove una applicazione userspace
ti impanica il kernel. Ma stiamo scherzando?
> Su Linux Kernel ml sarebbero felici di saperne di piu`,
> tu potendo riferire (ovvero avendone il tempo e/o riuscendo a
> trovarlo).
Trovare tempo, e trovare come fare il report.
Sinceramente, non l'ho mai fatto, di che dati avranno
bisogno?
E non solo ... nelle ultime tre sottoversioni (credo, ma non sono
sicuro,
2.6.29,30,31), sono riusciti a peggiorare le prestazioni del 10-15%;
il
che e` notevole, tanto che uno degli stessi sviluppatori (adesso non
mi ricordo quale) diceva che il migliore concorrente degli ultimi
kernel
usciti, e` Linux di due o tre versioni precedenti.
> Non è mica windows dove una applicazione userspace
> ti impanica il kernel. Ma stiamo scherzando?
Temo che il principio sia lo stesso, solo che qui si era meno
abituati.
> > Su Linux Kernel ml sarebbero felici di saperne di piu`,
> > tu potendo riferire (ovvero avendone il tempo e/o riuscendo a
> > trovarlo).
>
> Trovare tempo, e trovare come fare il report.
> Sinceramente, non l'ho mai fatto, di che dati avranno
> bisogno?
http://kernel.org/pub/linux/docs/lkml/reporting-bugs.html
http://www.kernel.org/pub/linux/docs/lkml/
Ma credo che ti saprebbero dire anche di piu` sul luogo.
Andrea