The wikis are now using the new authentication system.
If you did not migrate your account yet, visit https://idp-portal-info.suse.com/

SDB:Test de la stabilité du système

Aller à : navigation, rechercher


Version: 1.0 -

Besoin

Vous désirez vous assurer que votre matériel fonctionne de manière stable sous Linux.

Procédure

En supposant que vous avez installé les sources du kernel et les outils de développement nécessaire (compilateur, etc), vous pouvez, grâce au petit script suivant, tester la stabilité de votre système d'une manière très probante:

 #!/bin/bash
 #
 # Adapted from http://www.bitwizard.nl/sig11
 #

 cd /usr/src/linux

 t=1
 while [ -f log.$t ]
   do
   ((t++))
 done

 if [ ! -r .config ]; then
   echo -e
   echo -e "There was no .config file found in /usr/src/linux ."
   echo -e "This means that the kernel sources have not been configured yet."
   echo -e "If you continue "make cloneconfig" will be executed to create"
   echo -e "a kernel configuration based on the currently running kernel."
   echo -e "\n"
   echo -e "Press <Ctrl>-<C> to abort or <ENTER> to continue ..."
   read
   make cloneconfig
 fi

 touch log.1
 watch "ls -lt log.*" &

 while true
   do
   mv .config .config.stress
   make mrproper &> /dev/null
   mv .config.stress .config
   make V=1 > log.$t 2> /dev/null
   ((t++))
 done
 

Vous trouverez l'original de ce script sous http://www.bitwizard.nl/sig11. Vous y trouverez également des informations sur le fonctionnement de ces tests.

Les avantages de ce test en comparaison d'autres méthodes (p.ex. memtest86) sont

  1. le système entier va être testé: pas seulement la mémoire vive (RAM)
  2. le fonctionnement du système ne doit pas être interrompu durant ce test

Ce script compile, dans d'une boucle ininterrompue, les sources du kernel (make bzimage) et stocke la sortie de make pour chaque exécution de la boucle dans un fichier de journal (log) séparé. Ce dernier va grossir de manière importante.

On attend de ce test que le processus make produise lors de chaque exécution les mêmes sorties.

Le script montre pendant son exécution un état actualisé de

ls -l /usr/src/linux/log.*

La sortie ainsi produite pourrait avoir cette allure:

Every 2s: ls -lt log.*               Wed Aug  8 15:22:02 2001
-rw-r--r--    1 root     root         5472 Aug  8 15:22 log.4
-rw-r--r--    1 root     root       127120 Aug  8 15:21 log.3
-rw-r--r--    1 root     root       127120 Aug  8 15:12 log.2
-rw-r--r--    1 root     root       127120 Aug  8 15:04 log.1

Dans cet exemple, les trois premières exécutions sont déjà terminées. Le fait que les tailles des journaux soient identiques pour ces exécutions est déjà un bon signe. De manière à assurer un résultat de test fiable, il faudrait faire tourner le script jusqu'à 24 heures et ne pas juste se fier à la taille des fichiers. La commande md5sum est un outil approprié qui vous permet d'assurer que les fichiers de logs sont bien identiques:

linux:/usr/src/linux # md5sum log.*
51e25c01370ce034b2c00d4c71995f02  log.1
51e25c01370ce034b2c00d4c71995f02  log.2
51e25c01370ce034b2c00d4c71995f02  log.3
a014cc76b1fb46a3cc5b84484403a1b7  log.4

Le fait que le quatrième journal ait une autre somme de contrôle est normal: cette dernière exécution ne s'est pas encore terminée. Les sommes de contrôle des exécutions déjà terminées devraient elles toujours être identiques.

Remarque: Dans certaines circonstances, il peut arriver que la première exécution soit légèrement différente comparée aux exécutions subséquentes. Une règle simple est donc que toutes les exécutions sauf la première et la dernière (qui ne s'est pas encore terminée) doivent donner des résultats identiques.

en:SDB:General Hardware Problems

<keyword>crash,freeze,segmentationfault,signal11,sig11,memtest86,stabilité</keyword>