Crash du serveur avec des caractères ascii NUL dans syslog (^ @ ^ @ ^ @…)


21

J'ai un serveur dédié hébergé par un OVH (prestataire de services français). Système d'exploitation: Ubuntu 12.04 x64

Il y a quelques mois, l'un de mes serveurs est tombé en panne. La seule chose étrange était quelques caractères "ASCII NUL" dans le syslog:

^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @

Avec l'aide de mon fournisseur de services, nous avons vérifié:

  • Le bélier
  • Le CPU
  • Les disques

Tout allait bien, donc mon fournisseur de services a recommandé de changer la carte mère du serveur et de mettre à jour le noyau (ce que nous avons fait). Mais depuis, ce serveur s'est planté deux fois de plus, avec les mêmes caractères dans le syslog.

Sans plus d'explications, nous avons décidé de changer ce serveur (cela est prévu dans quelques semaines).

MAIS, le problème est que, cette nuit, cela est arrivé à un autre serveur. Même crash, mêmes caractères dans le syslog, aucune explication.

Quelqu'un at-il une idée de ce que nous devrions vérifier? Est-ce un problème matériel ou logiciel?


3
Avez-vous trouvé une solution à ce problème? Je souffre actuellement du même problème ...
BurninLeo

2
@BurninLeo: même ici
WoJ

En fait, je n'ai pas trouvé de solution (sur un serveur virtuel). Après un certain temps et quelques mises à jour (régulières) des versions stables, le problème a disparu ...
BurninLeo

5
Les octets NUL dans le syslog sont un effet courant d'un plantage qui a empêché le système de synchroniser et de démonter proprement le système de fichiers. Ils ne donnent aucune indication sur ce qui a réellement déclenché l'accident.
2017

Réponses:


8

Je partagerai plus largement l'excellente réponse donnée par @ n-st:

Les octets NUL dans le syslog sont un effet courant d'un plantage qui a empêché le système de synchroniser et de démonter proprement le système de fichiers. Ils ne donnent aucune indication sur ce qui a réellement déclenché l'accident.

En effet, j'ai souvent vu ce comportement après une panne de serveur: ces caractères sont des caractères NULL( \0) qui peuvent représenter un bloc récupéré qui a été rempli de zéros par un processus de récupération.

Quant à la cause de l'accident, c'est une toute autre question - vous auriez besoin de fournir bien plus d'informations pour qu'un diagnostic puisse même commencer. Je recommanderais d'ouvrir une autre question à ce sujet si le problème persiste.


-1

Si vous utilisez un éditeur de texte pour afficher les fichiers journaux, cela pourrait être la cause;

  • les caractères " ^@" peuvent indiquer qu'une ligne est trop longue (par exemple: dans vim, activez l' habillage )
  • L' encodage n'est pas compatible; utilisez un éditeur de texte différent pour afficher le fichier ou modifiez l'encodage utilisé par syslog.

4
J'ai le même problème. Ni une longue ligne ni l'encodage n'explique les caractères NUL à la fin du syslog (copié le fichier sur un disque externe et ouvert avec SciTE, encodage UTF-8).
BurninLeo

Il semble que vous puissiez ouvrir le fichier encodé UTF-8 dans un éditeur qui ne comprend pas très bien UTF-8. Cependant, cela pourrait être le problème CRLF (les commandes dos2unix et unix2dos peuvent être utiles)
Signal15

3
Les octets NUL dans le syslog sont un effet courant d'un plantage qui a empêché le système de synchroniser et de démonter proprement le système de fichiers. Ils ne donnent aucune indication sur ce qui a réellement déclenché l'accident.
2017

1
@ n.st Quelle excellente réponse! :) Vous devriez mettre celui-ci comme une "réponse"
Signal15
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.