Le débogage d'une machine Linux se bloque

9

J'ai 15 serveurs Linux RH 4.7 64 bits identiques. Ils exécutent la base de données de cluster (le cluster est au niveau de l'application). À l'occasion (tous les mois environ), une boîte aléatoire (jamais la même) se fige.

Je peux cingler la boîte et cingler fonctionne. Si j'essaye de ssh dans la boite j'obtiens:

ssh_exchange_identification: Connection closed by remote host

SSH est correctement configuré.

Lorsque je vais dans la salle des serveurs et que j'essaie de me connecter directement à la console, je peux changer de console avec Alt+ Fn, je peux entrer un nom d'utilisateur et les caractères s'affichent, mais après avoir appuyé Enter, rien ne se passe. J'ai attendu 8 heures une fois et cela n'a pas changé.

J'ai configuré syslog pour tout enregistrer sur un hôte distant, et il n'y a rien dans ces journaux. Lorsque je redémarre la machine, cela fonctionne sans problème. J'ai exécuté des tests HW - tout va bien et rien n'est dans les journaux. Les machines sont également surveillées avec NAGIOS, et il n'y a pas de charge ou d'activité inhabituelle avant le gel.

Je n'ai plus d'idées; que puis-je faire ou vérifier d'autre?

Luka Marinko
la source
Quels tests matériels avez-vous exécutés? Quels outils avez-vous utilisés?
tshepang
HW est HP proliant, j'ai utilisé leur util pour vérifier l'état RAID, les outils intelligents normaux ne fonctionnent pas, et j'ai utilisé memtest pour vérifier la mémoire. J'ai ce problème depuis plusieurs mois, et ce n'est jamais le même serveur.
Luka Marinko
Que suggère le support RedHat?
RedGrittyBrick
Luka, à la console, ne se passe-t-il rien après avoir entré juste le nom d'utilisateur et appuyé sur Entrée, ou vous demande-t-il le mot de passe et après cela ne répond pas?
mattdm
Si vous avez résolu le problème, veuillez modifier votre question pour décrire ce qui n'allait pas et ce que vous avez fait pour que les autres puissent le voir.
Thorbjørn Ravn Andersen

Réponses:

6

Il semble que votre noyau ait paniqué d'une manière ou d'une autre, de sorte que sshd n'a pas pu envoyer les clés du serveur. Il est possible que le noyau ait été calé de telle manière que la pile réseau soit toujours en place, mais la couche vfs n'était pas disponible.

Lorsque j'ai rencontré des problèmes similaires sur un système RHEL4, j'ai configuré les services netdump et netconsole , ainsi qu'un serveur netdump et syslog dédié pour capturer les vidages sur incident et les informations de panique du noyau. J'ai également défini le kernel.panic sysctl sur 10. De cette façon, lorsqu'un système panique, vous obtenez à la fois la trace du noyau et une copie de la mémoire sur ce système, que vous pouvez analyser avec l'utilitaire «crash».

Vous bénéficierez certainement également de la configuration d'une console série pour les hôtes, afin que vous puissiez voir la console éteinte et potentiellement frapper les touches magiques du système. De plus, si vous êtes prêt à configurer la mise en réseau et que vous avez du matériel qui le prend en charge, vous pouvez utiliser IPMI pour éteindre, mettre sous tension, redémarrer et interroger le matériel à distance.

(pour ce que ça vaut, RHEL5 a une fonctionnalité similaire avec kexec / kdump, seul le vidage sur incident est stocké localement)

jsbillings
la source
Salut, j'ai accès à la console directement (via KVM), et il n'y avait rien là-bas. Je pouvais basculer entre les types de terminaux virtuels dans mon nom d'utilisateur, mais c'est tout, également ctr + alt + del ne fonctionnait pas, mais devrait partir de la console.
Luka Marinko,
Les serveurs ont également le BIT de HP, je peux les redémarrer et voir les staus de HW à distance. Il n'y avait aucune erreur
Luka Marinko
Avez-vous vérifié les syslogs pendant cette période? Cela ressemble à un noyau paniqué. Je ne fais pas confiance aux KVM sur mes serveurs Linux, trop souvent la panique du noyau n'apparaît pas sur la console, ou elle est corrompue ou juste les deux dernières lignes, c'est pourquoi je préfère une console série.
jsbillings
1
Cela ne ressemble pas à une panique du noyau. La commutation de console fonctionne toujours et le programme de connexion est toujours actif.
mattdm
oui, j'ai fait rediriger Syslog vers le serveur Syslog central. Il n'y a rien d'inhabituel dans les journaux.
Luka Marinko, le
3

Je parierai des dollars pour des beignets que vous manquez de mémoire. Le système s'immobilise alors qu'il essaie de trouver d'où s'en procurer. Cela peut se produire si rapidement que votre surveillance ne le détecte pas. Je renforcerais la surveillance, y compris l'enregistrement à distance de l'utilisation de la mémoire. Vérifiez également dans les journaux les messages OOM.

(Vous voudrez peut-être même avoir des fenêtres ssh ouvertes en haut.)

mattdm
la source
3

Pour moi, cela semble que le système est à court de ressources, donc le processus requis par le côté serveur de ssh ne peut pas être alloué.

Le goulot d'étranglement réel peut varier - en dehors des processus ou de la mémoire - et la seule façon d'être sûr est de regarder les journaux et la console pour voir si quelque chose y est présent. Vous souhaiterez peut-être configurer un scénario de tâches ssh pré-démarrées - une pour chaque machine - simplement pour être préparé la prochaine fois que cela se produira.

Si c'est vraiment mauvais, alors vous voudrez peut-être envisager de démarrer un autre shell avec plus de commandes intégrées afin que vous puissiez en savoir plus sans avoir à démarrer un processus supplémentaire car cela peut ne pas être possible. "Tail -f / var / log / *" peut également être très utile.

Bonne chance.

Thorbjørn Ravn Andersen
la source
0

La seule fois où j'ai vu quelque chose de similaire, c'est où un commutateur KVM a été utilisé et une touche de raccourci clavier (par exemple alt + n) a été utilisée pour basculer entre les serveurs. Cela ne se produisait pas à chaque fois et c'était le serveur qui s'en éloignait qui était affecté - donc ce n'était pas immédiatement perceptible. Aucun blocage ne se produirait si un bouton physique sur le commutateur KVM lui-même était utilisé pour basculer entre les serveurs. Si la touche de raccourci était souvent utilisée, un serveur ne permettait parfois pas de nouvelles connexions. Les sessions SSH existantes n'ont pas été affectées.

RedGrittyBrick
la source