Debian11 fresh install : Freeze et multiple logs sysrq

Support Debian
#1

Bonjour,

J’aimerais avoir votre avis sur la situation suivante.

J’ai commandé chez OVH deux serveurs baremetal identiques sous debian11.
Je configure et/ou installe le réseau privé, fail2ban, ufw, webmin et mysql
J’avais à peine installé mysql sans le configurer que j’ai perdu par deux fois l’accès complet à un des deux serveurs via SSH, via webmin et la console IMPI bien qu’accessible n’acceptait aucune invite de commande.
Je retrouve l’accès en faisant un hard reboot
Je constate alors qu’entre 19h15 et le lendemain heure du reboot plus aucun log n’avait été généré par l’OS comme si le serveur était gelé complètement
Je note dans les logs de multiples :

sysrq: HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) show-blocked-tasks(w) dump-ftrace-buffer(z)

Je n’ai pas du tout ces logs dans l’autre serveur

D’après des cas similaires trouvés sur le net, cela pourrait être lié à des problèmes de connectique, de défaut d’alimentation électrique ou de port série :
https://forums.raspberrypi.com/viewtopic.php?t=73701

Le résultat de la commande cat /proc/sys/kernel/sysrq était 438, ce qui semble signifier que la fonctionnalité « Magic SysRq » est activée et que toutes les touches de raccourci « SysRq » sont autorisées.
Cela peut causer des messages de type « sysrq: HELP: loglevel … » dans les journaux du kernel si la touche « SysRq » est accidentellement pressée ou si un programme utilise cette fonctionnalité pour déclencher des fonctions de débogage.
J’ai désactivé cette fonctionnalité en modifiant la valeur de « sysrq » à « 0 » en utilisant la commande suivante :

echo 0 > /proc/sys/kernel/sysrq

Je n’ai depuis plus perdu l’accès au serveur.
Est-ce selon vous une bonne pratique ?

Le support d’OVH écarte tout problème matériel et me dit « il semblerait que vous alloué trop de RAM à un service/software » alors qu’il y encore zéro data dessus et que moins de 1% de la ram est actuellement allouée.

Commande top :

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                  
   1248 mysql     20   0 2342324 420188  37276 S   1.0   0.6  77:08.41 mysqld                                                                   
     38 root      20   0       0      0      0 S   0.3   0.0   0:01.89 ksoftirqd/5                                                              
  22475 root      20   0    7288   3636   2892 R   0.3   0.0   0:03.64

Qu’en pensez vous ?

Des données envoyées par un programme ou un device pourrait elle être intérpretée comme des commandes SYSREQ et déclencher un freeze du serveur ? Que feriez vous ?

Merci d’avance.

Elric

#2

Bonjour et bienvenue sur le forum,

Est-ce qu’il s’agit d’un IPMI qui te donne accès à un port série ou à une sortie vidéo ?

Oui, en effet, les problèmes qui ne semblent pas être matériels ne relèvent pas du support OVH.

#3

Bonjour,

Concernant l’IMPI c’est indiqué Serial Over Lan (SOL) .

Les seuls exemples que j’ai trouvé sur le net semblaient justement relever de problèmes matériels. C’est bien pour ça que je trouve la réponse d’OVH bateau, non documentée et peu probable dans la mesure où le serveur est vide et n’est pas sollicité.

#4

Juste une question bête, quand tu accèdes à l’IPMI pendant que le serveur est indisponible, tu vois rien du tout. Mais, est-ce que tu as tenté de saisir un identifiant ou une commande ?
La liaison série n’a aucune raison d’afficher quoique ce soit au moment où tu l’ouvres, il faut donc que tu fasses comme si elle était là et ça devrait apparaître.
Dis-moi si c’est clair et si ça t’aide à savoir ce qu’il se passe quand ton serveur n’est plus accessible autrement.

#5

Je voyais le curseur mais toutes les entrées aux claviers étaient sans effets. Dans le dév tools du navigateur, je voyais des erreurs javascrpt : "Refused to set unsafe header ‹ content-length ›. Même en me connectant via putty sur la console IMPI les entrées au clavier était sans effet. J’ai bien tenté de rentrer mes identifiants.

#6

D’accord, j’aurais tenté.

Vu que c’est une installation fraîche, ce que je peux te conseiller, c’est de refaire l’installation étape par étape et tester à chaque fois pour savoir à quel endroit ça comment à merder.
Tu peux éventuellement tester de faire une copie du système sur le serveur qui fonctionne pour voir si ça ne viendrait pas d’un truc que tu as bien fait sur un serveur, mais mal fait sur l’autre.

#7

Bonjour,
J’ai rebooté le serveur. Ce qui a remis la configuration par défaut de SYSREQ. Les logs SYSREQ help sont de suite revenus avec en plus
sysrq: This sysrq operation is disabled.
sysrq: Changing Loglevel

Le serveur est devenu inaccessible une fois puis deux fois.
OVH a retrouvé le serveur éteint
Il ont changé la RAM ce qui n’a rien changé
Le serveur continuait visiblement à s’éteindre seul
Ils ont fini par remplacer le serveur en gardant les disques

Tout semble fonctionnel à présent.
Ce n’était visiblement pas la configuration qui était en cause

Merci de votre assistance

1 J'aime
#8

Ah, ça fait plaisir à savoir.