Comment déterminer la cause d'un crash système?


10

Mon serveur se bloque environ une fois par semaine et ne laisse aucun indice sur la cause de ce problème. J'ai vérifié /var/log/messageset il arrête juste d'enregistrer à un moment donné et démarre à partir des informations de publication de l'ordinateur lorsque j'effectue un redémarrage dur.

Y a-t-il quelque chose que je peux vérifier ou un logiciel que je peux installer qui peut en déterminer la cause?

J'utilise CentOS 7.

Voici la seule erreur / problème dans mon /var/log/dmesg: https://paste.netcoding.net/cosisiloji.log

[    3.606936] md: Waiting for all devices to be available before autodetect
[    3.606984] md: If you don't use raid, use raid=noautodetect
[    3.607085] md: Autodetecting RAID arrays.
[    3.608309] md: Scanned 6 and added 6 devices.
[    3.608362] md: autorun ...
[    3.608412] md: considering sdc2 ...
[    3.608464] md:  adding sdc2 ...
[    3.608516] md: sdc1 has different UUID to sdc2
[    3.608570] md:  adding sdb2 ...
[    3.608620] md: sdb1 has different UUID to sdc2
[    3.608674] md:  adding sda2 ...
[    3.608726] md: sda1 has different UUID to sdc2
[    3.608944] md: created md2
[    3.608997] md: bind<sda2>
[    3.609058] md: bind<sdb2>
[    3.609116] md: bind<sdc2>
[    3.609175] md: running: <sdc2><sdb2><sda2>
[    3.609548] md/raid1:md2: active with 3 out of 3 mirrors
[    3.609623] md2: detected capacity change from 0 to 98520989696
[    3.609685] md: considering sdc1 ...
[    3.609737] md:  adding sdc1 ...
[    3.609789] md:  adding sdb1 ...
[    3.609841] md:  adding sda1 ...
[    3.610005] md: created md1
[    3.610055] md: bind<sda1>
[    3.610117] md: bind<sdb1>
[    3.610175] md: bind<sdc1>
[    3.610233] md: running: <sdc1><sdb1><sda1>
[    3.610714] md/raid1:md1: not clean -- starting background reconstruction
[    3.610773] md/raid1:md1: active with 3 out of 3 mirrors
[    3.610854] md1: detected capacity change from 0 to 20970405888
[    3.610917] md: ... autorun DONE.
[    3.610999] md: resync of RAID array md1
[    3.611054] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
[    3.611119] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for resync.
[    3.611180] md: using 128k window, over a total of 20478912k.
[    3.611244]  md1: unknown partition table
[    3.624786] EXT3-fs (md1): error: couldn't mount because of unsupported optional features (240)
[    3.627095] EXT2-fs (md1): error: couldn't mount because of unsupported optional features (244)
[    3.630284] EXT4-fs (md1): INFO: recovery required on readonly filesystem
[    3.630341] EXT4-fs (md1): write access will be enabled during recovery
[    3.819411] EXT4-fs (md1): orphan cleanup on readonly fs
[    3.836922] EXT4-fs (md1): 24 orphan inodes deleted
[    3.836975] EXT4-fs (md1): recovery complete
[    3.840557] EXT4-fs (md1): mounted filesystem with ordered data mode. Opts: (null)

Réponses:


5

Vous pouvez vérifier le fichier dmesg à /var/log/dmesg, qui enregistre les messages du noyau. Le journal des messages ne fait que consigner les messages des services et des applications et si vous avez une erreur de noyau, les services et les applications cesseront de fonctionner, mais l'erreur de noyau est toujours enregistrée dans dmesg.


J'ai vérifié dmesg et dmesg.old, les deux ne contiennent que les informations de démarrage (environ 4,8 secondes). Le seul "problème" que je peux voir est que le disque de démarrage ou les lecteurs RAID semblent avoir quelque chose de mal mais le système le corrige et fonctionne malgré tout. Vérifiez le message principal pour le lien.
Brian Graham

5

Si vous avez crashkernel/kdumpinstallé et activé, vous devriez être en mesure d'examiner le noyau en panne avec relativement facile à l'aide de l' crashutilitaire. Par exemple, en supposant que vous avez planté les vidages du noyau sont enregistrés sous /var/crash: crash /var/crash/2009-07-17-10\:36/vmcore /usr/lib/debug/lib/modules/uname -r /vmlinux.

Jetez un œil ici et ici pour plus de détails.


J'ai réparé l' /dev/md1 not founderreur lors de l'exécution grub2-probeet installé et configuré crashkernel / kdump et je signalerai si / quand il se bloque à nouveau.
Brian Graham

2
  • test de mémoire du bios
  • test du disque dur du bios
  • Vérifier le journal du lecteur intelligent smartctl /dev/sda -a
  • Tests de conduite intelligents
  • laisser dmesg -wHcourir dans une fenêtre

J'ai effectué des tests de lecteur intelligents sur les 3 disques, ils ne sont pas corrompus. J'ai dmesg -wHexécuté dans une fenêtre (je suppose jusqu'à ce qu'il se bloque à nouveau; et je peux toujours lire la sortie après le crash via SSH). Je n'ai pas d'accès physique à la machine, dois-je demander à mon hôte d'exécuter les tests de mémoire du bios et de disque dur?
Brian Graham
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.