Crash système - caractères étranges dans syslog

J'ai un petit serveur que j'utilise pour les tests et la programmation. Actuellement, il exécute l' étirement Debian 9.4 avec le noyau 4.14.0-0.bpo.3-amd64 .

Aujourd'hui, j'ai essayé de me connecter via SSH mais je n'ai pas pu alors j'ai essayé de le cingler et c'était inaccessible. Par conséquent, j'ai dû le redémarrer en débranchant le câble d'alimentation. Ensuite, je suis allé /var/log/syslog et j'ai trouvé une étrange ligne contenant exactement 6140 caractères comme le suivant

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

puis rien d'autre jusqu'au redémarrage des nouvelles entrées de journal du système. C'est en fait la première fois que cela se produit.

Est-ce que quelqu'un sait ce que cela pourrait être?

debian logs

— DrKey
source

Eh bien, j'ai écrit à ce sujet sur askubuntu.com/a/1020373/43344 , pour commencer . (-: Ensuite , il y a unix.stackexchange.com/questions/227173 et unix.stackexchange.com/questions/237321 ...

— JdeBP

@JdeBP Je préfère votre première réponse / lien, c'est bien ça. Odd a une question avec plus de 1500 visites, vous n'avez pas obtenu un seul vote, +1.

— Rui F Ribeiro

Réponses:

Le contenu du fichier syslog que vous nous montrez de tous les zéros est en effet une corruption de l'écriture du système de fichiers / syslog.

Votre crash système a pris le système en cours d'écriture dans le fichier syslog, et c'est le résultat final.

Je l'ai déjà vu plusieurs fois au fil des ans, dans les machines virtuelles Linux et quelques fois de plus dans Raspberries et Banana Pis.

Rien à obséder (trop) ou à perdre beaucoup de temps pour rechercher pourquoi vous avez ceci pour un événement unique. Je serais plus inquiet de savoir pourquoi il s'est écrasé, surtout s'il s'agit d'un événement régulier.

PS entrant dans un territoire anecdotique, la dernière fois que cela se produisait régulièrement dans un Banana Pi R1, j'ai réussi à retracer la cause d'un chipset wifi realtek (défectueux).

— Rui F Ribeiro
source

Il convient également de noter qu'il ^@s'agit de l'octet NUL (valeur d'octet 0), il s'agit donc de données "vides" qui sont ajoutées au fichier journal par accident. Cela peut se produire, par exemple, lorsqu'un nouveau bloc vide est affecté à la fin du fichier, mais que la quantité d'octets réellement occupés par des données significatives dans ce bloc n'est pas mise à jour correctement (car le crash / réinitialisation matérielle s'est produit avant que ce compteur ne soit engagé dans le lecteur).

— marcelm

comment savoir pourquoi il s'est écrasé?

— PDG de l'Apartico le

@CEOatApartico Je conseille d'ouvrir une nouvelle question.

— Rui F Ribeiro

@RuiFRibeiro unix.stackexchange.com/questions/528275/…

— PDG d'Apartico le

Pour développer légèrement cette réponse , votre syslog a le contenu d'une page de mémoire partiellement engagée sur le disque, les métadonnées de syslog n'étant pas à jour. Cette chaîne de ^@caractères est en fait NUL octets; exactement ce qu'une page de mémoire fraîchement allouée contient initialement.

— Jarhmander
source

Un rappel amical: si vous allez le baser dans la réponse JdeBP, essayez de bien faire les choses. Les secteurs de disque sont mis à zéro lorsqu'ils sont alloués par le noyau pour des raisons de sécurité, ce n'est pas de la mémoire avec des 0 en cours d'écriture en soi. Je conseille de corriger cela.

— Rui F Ribeiro