slacky.eu

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.

E difatti anche oggi si è verificato lo stesso problema.

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!

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

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.

ciafo ha scritto: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.

Riprendo questo vecchio topic perchè la problematica è ancora viva.

Una mesata fa mi è capitato di doverle ancora rirebootare dopo c.a. 300gg di uptime (ovvero dai reboot sopraindicati).
Stesso problema.
Allo shutdown, al termine di tutto, il processo 'reboot' si è rifermato a schermata nera invece di partire con il boot (bios ecc).
il kernel era 2.6.18-308.24 di redhat 5.5
ora hanno 30gg di uptime.


In teoria (ma solo teoria) tra qualche mese dovrò rebootare le gemelle che hanno 500gg di uptime (ma secondo me non verrà fatto visto che è produzione).

In compenso ne ho 4 con 600gg di uptime che credo di poter rebootare quando voglio (anche se mi dispiacerebbe perdere tutto questo uptime).

ZeroUno ha scritto:In teoria (ma solo teoria) tra qualche mese dovrò rebootare le gemelle che hanno 500gg di uptime (ma secondo me non verrà fatto visto che è produzione).

Ci siamo...
ma stavolta lo so in anticipo.

La settimana prossima dovrò riavviare le 8 macchine di produzione.

Per riassumere, le macchine in oggetto sono 6 SUN FIRE X4170 e 2 FUJITSU PRIMERGY RX600 S5, con quasi 600gg di uptime l'una. Hanno Red Hat Enterprise Linux Server 5.x; la metà di queste hanno versione 5.5 con kernel 2.6.18-194.el5 e l'altra metà 5.4 con kernel 2.6.18-164.el5. L'attività serve per patcharle e portarle alla 5.8 con kernel 2.6.18-371.el5
Il mio parco macchine contiene c.a. una ventina di queste macchine, e tutte le volte che le ho dovute riavviare dopo un lungo periodo di uptime (quindi poche volte, visto che ce l'ho da poco più di 3 anni) sono arrivati fino allo shutdown, hanno passato la system call del 'reboot system'&'acpi' e poi si sono fermate a schermata nera, senza ricominciare il post del bios, come se avessi fatto halt anzichè reboot.
Unico modo per farle risalire, poweroff forzato dalla console di amministrazione (ilom).
Tutte le ipotesi fanno acqua da tutte le parti.
Il bios delle SUN risale a giugno 2009; il bios delle FUJITSU a marzo 2011, ma tutte hanno lo stesso comportamento

Che controlli posso fare preventivamente?

Avevo visto questo thread un po' di tempo fa, però poi l'avevo perso di vista. Un bel grattacapo, mai sentita una cosa del genere.

Escludendo il BIOS e problemi HW (che su un numero così elevato di macchine sembrano improbabili anche a me), deve esserci per forza qualcosa di comune a tutti i server che causa questo comportamento anomalo.

Le macchine stanno tutte nella stessa sala?
Se sì, il problema potrebbe essere lì.

Sono attaccate allo stesso ramo dell'impianto elettrico? Sono tutte collegate allo stesso tipo di gruppo di continuità? Potrebbe essere un bug nella gestione dell'UPS?

Quelle 8 sono tutte in quel datacenter, ma ne ho altre (che rebooterò fra 3/4 settimane) a 500 kilometri di distanza, e questo credo che escluda il problema impianto elettrico.
Stessi modelli e stessi difetti.

I problemi HW si escludono per il numero elevato, ma il bios si esclude solo perché sono di 2 modelli diversi, altrimenti sarebbe il primo indiziato.
E sono sicuro che apro un ticket di assistenza la prima cosa che mi farebbero fare sarebbe l'aggiornamento del bios (è di default; qualsiasi problema ti dicono 'installa gli aggiornamenti', manco fosse Windows). E poi ti direbbero che funziona, anche se per sapere se è vero devi aspettare almeno un anno per avere un decente uptime .

Purtroppo non credo di averne altre con kernel diverso, tutte 2.6.18.

Provato a chiamare i Ghostbusters?

Scherzi a parte, purtroppo non mi viene nulla di plausibile in mente, a parte ovviamente il kernel, che è lo stesso per tutte le macchine. Passi qualche parametro particolare al kernel in fase di boot?
Comunque, visto che a questo punto sai già che se il reboot dovesse fallire dovrai riavviarle manualmente, non puoi provare a spegnerne e riaccenderne una normalmente? Così vedi se almeno lo shutdown va a buon fine o meno.

intendi init 0 invece di 6?
Giusto, ci proverò.
Parametri particolari non mi sembra, domani controllo

edit: i parametri sono "ro root=LABEL=/ rhgb quiet"

Mi sbagliavo... con le FUJITSU il problema non si presenta. O almeno... ora ne ho riavviata una e non mi ha dato problemi.

Queste macchine non vedono il reboot da oltre 600 giorni, ma credo che lo shutdown non l'abbiano mai visto in vita loro

Ho dato init 0 sull'ultima macchina.

Il sistema è arrivato tranquillamente in Power State Off (quindi non forzato, perchè mi sembra che in passato, quando si è presentato il problema la prima volta, dovevo dare un Power Off forzato, che è equivalente a staccare la corrente).
E dando il power on si è accesa e ha fatto il boot normalmente.

Dentro il mese, credo, devo fare la stessa operazione su altre macchine gemelle, ma queste hanno solo 380gg di uptime.

Scusate se m'intrometto con qualche banalità, ma...

There are two kernel options specified, ’rhgb’ and ‘quiet’

rhgb stands for redhat graphical boot. This is a GUI mode booting screen with most of the information hidden.
quiet parameter hides the majority of the boot messages before rhgb starts.

Io le toglierei per vedere qualche messaggio in più. Immagino che in /var/log (o dove Red Hat li piazza, sono anni che non la uso) tu non abbia trovato niente di utile.

Vedo che il bios della Sun Fire ha qualche utility di logging. Hai già guardato anche lì?

Se elimini l'impossibile, quello che rimane, per quanto improbabile, deve essere la verità

(Cit. Spock che cit. Sherlock Holmes) e allora l'unica spiegazione è lo Spirito nel guscio.