Il debug della macchina Linux si blocca

Ho 15 identici Linux RH 4.7 a 64 bit. Eseguono il database del cluster (il cluster è a livello di applicazione). A volte (ogni mese circa) si blocca una scatola a caso (mai uguale).

Posso eseguire il ping della casella e il ping funziona. Se provo a ssh nella casella ottengo:

ssh_exchange_identification: Connection closed by remote host

SSH è impostato correttamente.

Quando vado nella sala server e provo ad accedere direttamente alla console, posso cambiare console con Alt+ Fn, posso inserire un nome utente e i caratteri vengono visualizzati, ma dopo aver premuto Enter, non succede nulla. Ho aspettato 8 ore una volta e non è cambiato.

Ho impostato syslog per registrare tutto su un host remoto e non c'è nulla in quei registri. Quando riavvio la macchina, funziona senza problemi. Ho eseguito test HW: tutto è ok e non c'è nulla nei registri. Le macchine sono inoltre monitorate con NAGIOS e non vi sono carichi o attività insoliti prima del congelamento.

Ho finito le idee; cos'altro posso fare o controllare?

Sembra che il tuo kernel sia in preda al panico in qualche modo tale che sshd non possa inviare le chiavi del server. Probabilmente, il kernel è stato incastrato in modo tale che lo stack di rete fosse ancora attivo, ma il livello vfs non era disponibile.

Quando ho riscontrato problemi simili su un sistema RHEL4, ho impostato i servizi netdump e netconsole e un server netdump e syslog dedicato per rilevare i dump di arresto anomalo e le informazioni di panico sul kernel. Ho anche impostato il kernel.panic sysctl su 10. In questo modo, quando un sistema va nel panico, ottieni sia la traccia del kernel che una copia della memoria su quel sistema, a cui puoi analizzare con l'utility 'crash'.

Avresti sicuramente trarre vantaggio dall'impostazione di una console seriale per gli host, in modo da poter vedere la console emessa e potenzialmente colpire le chiavi magiche di sysrq. Inoltre, se si desidera configurare la rete e si dispone di hardware che la supporta, è possibile utilizzare IPMI per spegnere, riaccendere, riavviare e interrogare in remoto l'hardware.

(per quello che vale, RHEL5 ha una funzionalità simile con kexec / kdump, solo il dump dell'arresto anomalo viene archiviato localmente)

Scommetto dollari a ciambelle che stai esaurendo la memoria. Il sistema si sta arrestando mentre cerca di capire da dove ottenerne alcuni. Potrebbe accadere così rapidamente che il tuo monitoraggio non lo rileva. Potrei intensificare il monitoraggio, incluso il log remoto dell'utilizzo della memoria. Controlla anche nei log i messaggi OOM.

(Potresti anche solo voler aprire alcune finestre ssh in esecuzione.)

A me sembra che il sistema abbia esaurito le risorse, quindi il processo necessario dal lato server di ssh non può essere allocato.

Il collo di bottiglia effettivo può variare - a causa di processi o memoria insufficiente - e l'unico modo per essere sicuri è quello di guardare i registri e la console per vedere se qualcosa è presente lì. Potresti voler creare uno scenario di lavori ssh pre-avviati - uno per ogni macchina - semplicemente per essere preparato la prossima volta che succede.

Se è davvero male, allora potresti prendere in considerazione l'idea di avviare un'altra shell con più comandi integrati in modo da poter indagare di più senza dover avviare un processo aggiuntivo in quanto ciò potrebbe non essere possibile. Anche "tail -f / var / log / *" può essere molto utile.

In bocca al lupo.

L'unica volta che ho visto qualcosa di simile è stato l'uso di uno switch KVM e un tasto di scelta rapida da tastiera (ad esempio alt + n) per passare da un server all'altro. Non è accaduto ogni volta ed è stato interessato il server a passare da quello a essere interessato - quindi non è stato immediatamente evidente. Non si verificherebbero blocchi se si passasse da un pulsante fisico allo switch KVM stesso per passare da un server all'altro. Se il tasto di scelta rapida veniva spesso utilizzato, a volte un server non consentiva nuovi accessi. Le sessioni SSH esistenti non sono state interessate.