Reboots intempestifs debian 6

Support Debian
#1

Bonjour à tous,

Je voudrais vous soumettre une énigme que j’ai beaucoup de mal à élucider :

Je dispose de plusieurs petits serveurs déployés, installés sur une base debian 6 (2.6.32-5-686)
Je rencontre depuis plusieurs mois, le souci suivant :

  • Le serveur semble effectuer un hard reboot de façon intempestive
  • Suite à ce reboot, au démarrage, le bios ne trouve plus son disque dur et affiche un message de type “cannot find boot device, press any key to continue”
    – A ce stade, que ce soit par un CTRL-ALT-SUPP, le bouton reset, rien n’y fait, pas de boot possible sur le disque.
  • seule solution, couper électriquement le serveur puis le rallumer, démarrage ok sur le disque, situation normale.

De plus :

Les hard reboots provoquent des soucis aléatoires qui semblent être les conséquences de corruption de mémoire ou de données :

  • reboot avec perte d’une partition (partition root bien sur … )
  • corruption du filesystem (XFS)
  • création de caractères aléatoires dans des fichiers, certains pouvant empêcher le démarrage correct)
  • corruption de la MBR (données incohérente dans la structure de la MBR)
  • perte de la configuration complète du BIOS (date, heure, settings personnalisés)

Précisions :

  • Les serveurs sont installés soit sur disque SSD soit sur compact flash (tests d’au moins trois type différent de chaque)
  • disques SSD SLC industriels wide temperature, carte CF industrielle WT
  • mémoire SO DIMM industrielle

Dans le cas des hard reboot, rien dans les logs (ceux-ci s’arrêtent à l’heure précise du reboot, sans précision)

D’après les premières analyses, il semblerait qu’à un moment, on ne puisse plus du tout joindre le disque/carte à partir du système (j’ai déja vu des messages d’IO disque error avant un crash)

mes interrogations :

Comment e système peut-il avoir un lien avec une corruption du BIOS ? via la mémoire ?
Se pourrait-il que le système perde vraiment le disque dur (mise en veille, perte controleur, driver du kernel ?)
J’ai beaucoup de mal à voir l’interaction entre le hard reboot système et la corruption du BIOS (corruption temporaire puisque le fait de rafraichir électriquement la machine permet de repartir)
-l’ACPI pourrait-il être une cause de souci pour un serveur debian 6 ?

  • Est-il possible de positionner plus de traces au niveau noyau pour analyser le crash initial et la cause du hard reboot ?

Le souci semble être plus fréquent si il y a beaucoup (c’est relatif) de volume qui transite.

Si vous avez quelques pistes ou outils d’analyse à me proposer, je vous en serait reconnaissant.

Bonne journée

Cordialement

#2

Suivant tes symptômes je pencherais pour un problème matériel.
Genre un condensateur gonflé, une alim un peu trop juste/instable, carte mère défectueuse, …
Et qui du coup avec un peu trop de charge génère un comportement aléatoire.

Tu as fait des tests du stockage, mais quand est il de la mémoire/proc/carte mère ?

#3

Merci pour ton retour,

J’ai également fortement pensé à un problème matériel mais :

  • mémoire testée tout un WE avec memtest = OK
  • problème survenu sur plusieurs machines (mais avec exactement le même hardware) incompatibilité ?
  • test disques ok (avec smartctl et testdisk)
#4

Et pour l’alim ? Si toutes les machines on la même et qu’elle est un peu juste il est normal d’avoir les même symptômes.
Sinon une incompatibilité est probable, mais là ça dépasse mes compétences :confused:

#5

Bon, j’ai … un peu … avancé sur ce souci. Je connais l’origine des reboot :

  • un script maison de sécurité qui vérifiait périodiquement si il était possible d’écrire sur le disque/carte (création d’un fichier dans le /tmp), si la création du fichier échouait, le script provoquait un reboot de la machine

  • Ce reboot pouvait planter avec soit le bios en vrac, soit le filesystem XFS en vrac

En inhibant ce script, effectivement la machine ne redémarre plus, mais … le problème est toujours là, ce qui provoquait le déclenchement du script (impossible d’écrire sur le disque) se matérialise maintenant par une série de message d’erreur en console, et la machine plantée.

  • pour rappel, le souci se passe sur un grand nombre de serveurs identiques, donc il ne s’agit pas d’une panne isolée pouvant être liée à un disque dur défectueux ou une barrette de mémoire (néanmoins, une incompatibilité kernel/hardware spécifique n’est pas à exclure)

donc maintenant, au plantage, j’obtiens un dump d’erreur qui semble lié à XFS :

ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata1.00: failed command: WRITE DMA
ata1.00: cmd ca/00:14:5c:4a:23/00:00:00:00:00/e0 tag 0 dma …
…
…
ata1.00: status: ( DRDY )
ata1: SRST failed (errno=-16)
ata1: SRST failed (errno=-16)
ata1: SRST failed (errno=-16)
ata1: SRST failed (errno=-16)
ata1: reset failed, giving up
…
…
I/O error on device /dev/sda3, logical block 353148
I/O error on device /dev/sda3, logical block xxxxxx
I/O error on device /dev/sda3, logical block xxxxxx
I/O error on device /dev/sda3, logical block xxxxxx
I/O error on device /dev/sda3, logical block xxxxxx
I/O error on device /dev/sda3, logical block xxxxxx
…
…
device sda3, XFS metadata write error block 0x8b550 in sda3 …
I/O error in filesystem (“sda3”) meta-data dev sda3 block 0x1bf …
(“xlog_iodone”) error 5 but count 16384
Filesystem “sda3”: Log I/O Error Detected. Shutting down filesystem
Please unmount the filesystem and rectify the problem(s)
I/O error in filesystem (“sda3”) meta-data dev sda3 block 0x1bf …
(“xlog_iodone”) error 5 but count xxxxx
I/O error in filesystem (“sda3”) meta-data dev sda3 block 0x1bf …
(“xlog_iodone”) error 5 but count xxxxx
I/O error in filesystem (“sda3”) meta-data dev sda3 block 0x1bf …
(“xlog_iodone”) error 5 but count xxxxx
…
I/O error in filesystem (“sda3”) meta-data dev sda3 block 0x1bf …
(“xlog_trans_read_buf”) error 5 but count 512

  • Mais je pense que ce dump XFS est aussi une conséquence du problème, le script n’arrivzit plus à écrire sur le disque, le dump XFS semble trouver des soucis d’IO sur le disque également, ça tourne autour de cela.

mais si je fais des tests du/des disques, pas de souci, testdisk OK, outils smart également.

à s’arracher les cheveux !