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

Question

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/messages et il arrête simplement l'enregistrement à un moment donné et démarre à partir des informations de publication de l'ordinateur lorsque j'effectue un redémarrage matériel.

Y a-t-il quelque chose que je peux vérifier ou un logiciel que je peux installer qui peut 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)

TooCloudy · Answer

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.

shodanshok · Answer

Si tu as crashkernel/kdump installé et activé, vous devriez pouvoir examiner le noyau en panne avec une facilité relative en utilisant l'utilitaire crash. Par exemple, en supposant que vous avez bloqué 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 oeil ici et ici pour plus de détails.

Jim U · Answer

test de mémoire bios
test du disque dur du bios
Vérifiez le journal du lecteur intelligent smartctl /dev/sda -a
Lecteur intelligent tests
partir dmesg -wH en cours d'exécution dans une fenêtre