server che non fanno il reboot

[ZeroUno]

Ho dei server SUN FIRE X4170 SERVER con redhat 5.5 kernel 2.6.18-194.el5

Queste macchine hanno un alto uptime (poco meno di due anni) ma ora per attività di manutenzione una alla volta le devo riavviare tutte.

finora è stato un disastro quasi su tutte.

Ne sono rimaste solo due, da riavviare una a pranzo e una a cena, quindi non ho più tentativi (considerando che sono di produzione e il downtime massimo che ci possiamo permettere è un'ora).

Cosa è successo? Presto detto.

Le macchine non si sono riavviate.

Dato il comando "reboot" (via ssh) le macchine non si raggiungevano più anche dopo diversi minuti (non risalivano).
Connessi in console, via ilom in https, veniva una schermata nera, la stessa che compare dopo che il kernel scrive "rebooting.." che però di solito in un pc dura un paio di secondi, 30 al massimo in un server.
Unica soluzione è collegarsi alla ILOM e forzare il power off del sistema (l'equivalente di tenere premuto il pulsante di spegnimento di un pc) e riaccenderlo.
Questa volta quella schermata dura veramente una trentina di secondi e poi la macchina riparte tranquillamente.
Le macchine che abbiamo riavviato ieri non hanno presentato il problema, ma avevano un uptime di soli 270gg.
Quelle odierne (30 maggio) invece (più di 600gg di uptime) hanno presentato questo problema.
Quelle di domani hanno una una 372gg e l'altra 572gg di uptime.

Stesso problema verificatosi con macchine gemelle con altrettanto alto uptime ma non di produzione un paio di mesi fa.
Non essendo di produzione mi sono potuto permettere un reboot in più, e al secondo reboot non c'è stato bisogno di forzare il power off.

Che può essere e soprattutto che posso fare per evitare che non risalgano?

Ho pensato ad un sacco di pure teorie che però fanno acqua da tutte le parti ed entrano nel campo dell'immaginario.
Quì si gioca nel fondo del kernel (in tutti i sensi, soprattutto quello dell'ultima operazione eseguita dal kernel: l'invio del comando di reset della macchina al processore o chissà quale altro componente della macchina).
Una teoria è che dopo tanto tempo per qualche motivo si sia sporcata un po' la memoria a livello di contenuti (per bug?) o a livello elettrico, e il comando di reset non ha resettato il processore (o qualche altra periferica) completamente da zero causando un comportamento non previsto.

cosa ne pensate?

Verso fine giugno c'è un weekend di disservizio programmato e forse (e dico FORSE) potrò riavviare i sistemi. Di sicuro c'è che devo spengere i servizi e smontare i filesystem.

[ZeroUno]

E difatti anche oggi si è verificato lo stesso problema.

[joseph]

Ci girano demoni particolari su queste macchine? mi vien da pensare un timeout eccessivo nella chiusura dei processi...ma credo sia poco attendibile come spiegazione...Bisognerebbe fare delle prove ma visto che sono macchine di produzione e che non puoi "fare tentativi" a naso è anche un pò difficile capire il problema!

[ZeroUno]

Non si tratta solo che non posso fare tentativi perchè sono di produzione. Ho anche macchine non di produzione (con cui posso giocare relativamente).
Il "mi restano due tentativi" significa che solo due macchine avevano ormai alto uptime, le altre sono state tutte riavviate ieri e l'altro ieri. E oggi ho riavviato anche le due rimanenti. Il significato di quella frase è che dopo averle riavviate la prima volta, i reboot successivi vanno tutti a buon fine.

Per quanto riguarda il timeout dei processi lo escludo (anche se è sicuramente più attendibile della mia di spiegazione, che parla di impulsi elettrici e instabilità che, se fosse vero, si verificherebbe solo per qualche macchina e non per tutte quante).
La console ce l'ho e posso vedere quello che fa il sistema. La procedura di shutdown arriva fino in forndo, quando dice rebooting system, poi da (veloci, quindi non ho potuto vedere i dettagli) messaggi sull'ACPI, poi schermata nera.
Ho contato che il tempo corretto che quella schermata deve rimanere nera è di c.a. 75 sec. (come avviene nei reboot successivi).

[ciafo]

La butto li. Il problema potrebbe essere che, una volta che il SO ha finito la sua attività, passa il controllo al BIOS attraverso l'IRQ del restart ed il BIOS effettivamente effettua dei controlli prima di spegnersi (o restartarsi).Potrebbe quindi essere che il BIOS trova qualcosa che non va (magari un blocco ram non funzionante perfettamente) e cerca di recuperare l'hardware oppure è solo una gestione errata del PM (power management) che spegne il controllo per il reboot e, quando viene effettuato, lo deve ricaricare.

[ZeroUno]

Potrebbe quindi essere che il BIOS trova qualcosa che non va (magari un blocco ram non funzionante perfettamente)

su 20 macchine?

oppure è solo una gestione errata del PM (power management) che spegne il controllo per il reboot e, quando viene effettuato, lo deve ricaricare.

perchè ai reboot successivi non avviene?
Tra l'altro nella funzione 'reboot', differentemente da 'halt', non dovrebbe essere interpellato il power management.