Ce texte en cours de rédaction peut permettre de découvrir pour quelle raison un programme ne fonctionne pas correctement. Il ne s'agit ici que de dysfonctionnements "système", c'est-à-dire dûs à un contexte d'exploitation donné et non à un algorithme inadéquat sur le plan fonctionnel (qui ne "fait pas" ce que l'on souhaite).
Notes : cette "checklist" n'abrite rien d'original et n'intéressera pas les utilisateurs confirmés.
Tester diverses options, modes de fonctionnement, données à traiter afin de
déterminer ce qui fonctionne ... ou pas.
S'assurer que l'on dispose bien d'espace-disque (commande df),
que les répertoires temporaires (/tmp, /var/tmp
...) ne sont pas saturés, essayer après mise à zéro de toutes les variables
d'environnement douteuses (utiliser printenv pour les
examiner et, sous bash, export NOM_VARIABLE= pour les
supprimer.
Si le programme crashe sur réception d'un "signal 11" lire la FAQ signal 11
Ne pas oublier les pages de manuel et le 'homepage' du projet. Les
utilisateurs de Red Hat ou de Slackware liront les fichiers placés sous
/usr/doc/nom_du_programme*.
S'assurer que tous les composants requis (bibliothèques, éditeur de liens dynamiques, serveur X ...) sont bien installés.
Recompiler, car certains sources de programmes (surtout des utilitaires) engendrent des binaires dépendants de la version du noyau utilisé lors de leur compilation.
Recompiler sans optimisations (pas de "-m486" ni de "-O..." mais avec "-fno-strength-reduce").
Dériver au besoin le canal de sortie standard et celui réservé aux erreurs vers un fichier. Invoquer pour cela (sous bash) :
nom_du_programme >& nom_du_programme.sortie.tmp
bash -x nom_du_programme >& nom_du_programme.sortie.tmp
Puis lire le contenu du fichier
nom_du_programme.sortie.tmp. Si un message produit n'est pas
compréhensible rechercher dans le fichier
/usr/src/linux/include/asm/errno.h le mystérieux code d'erreur
ou mot-clé.
En cas de problème de partage de ressources (surtout reliées au port série) surveiller le contenu de /var/lock en-dehors et durant des connexions.
Ne pas négliger d'examiner les fichiers de trace (log). De
nombreux programmes, au prix d'un paramétrage adéquat, enregistrent de
façon plus ou moins complète et détaillée l'historique de leur
activité.
Les fichiers de trace se trouvent le plus souvent dans le répertoire
/var/log/. S'y placer et lire les dernières lignes des derniers
fichiers modifiés (utiliser "ls -ltr" puis "less" et la touche 'G').
Ou utiliser grep afin de trouver les noms des fichiers contenant
des lignes relevant du programme en cours d'examen. Par exemple (cas de
sendmail) :
grep -l sendmail *
Mais certains programmes laissent des historiques ailleurs. Il faudra de toutes façons lire leurs documentations afin de déterminer :
ps auxw | grep syslogd | grep -v grep
Cela doit produire une ligne ressemblant à ceci :
root 114 0.0 0.6 968 404 ? S 10:13 0:01 syslogd
Si ce n'est pas le cas on pourra tenter, en tant que root, d'invoquer
/usr/sbin/syslogd puis réexecuter la commande précedente afin
de vérifier. En cas d'échec il faudra installer ce programme (Red
Hat : paquet sysklogd).
Sitôt syslogd actif l'utilisateur root peut sauvegarder le
fichier /etc/syslog.conf et créer, s'il n'existe pas encore,
le répertoire d'accueil des fichiers de trace :
cd /etc
cp -i /etc/syslog.conf /etc/syslog.conf.ok
mkdir /var/log
Puis éditer /etc/syslog.conf afin d'y ajouter une ligne :
* /var/log/tous_messages.tmp
Envoyer un signal hangup au processus syslogd afin de l'obliger à relire son fichier de configuration. Profitons aussi de l'occasion pour n'autoriser que root à lire ce fichier (il peut contenir des informations confidentielles si certains programmes "logent" des mots de passe) :
kill -HUP `cat /var/run/syslog.pid`
chown /var/log/tous_messages.tmp
chmod o= /var/log/tous_messages.tmp
Le processus syslogd consigne dès lors tous les messages du système dans
le fichier /var/log/tous_messages.tmp. Ouvrir une autre
console en tant que root puis invoquer :
tail -f /var/log/tous_messages.tmp
tail actif, une simple
combinaison de touches control-c le stoppera en fin de session.
Relancer alors le programme incriminé, si possible en mode "debug" et
"verbose", et surveiller la console sur laquelle écrit le processus
tail. Avec un peu de chance divers messages révélateurs
apparaîtront.
Ne pas oublier, en fin de session, de restaurer la configuration de syslogd :
cd /etc
cp -i /etc/syslog.conf /etc/syslog.conf.debug
cp -i /etc/syslog.conf.ok /etc/syslog.conf
kill -HUP `cat /var/run/syslog.pid`
Si les binaires proviennent d'une source sûre invoquer le programme en tant que root. Si tout fonctionne bien ainsi le problème relève très probablement des permissions.
Lancer le programme sous strace. Cet outil dresse liste, au fur et à mesure de l'exécution d'un binaire, des appels à la librairie système (la fameuse "libc").
Exemple : lorsque le programme fonctionne bien si root l'emploie mais mal sinon on pourra comparer ainsi les contextes :
strace -s80 -onom_programme.user.trace nom_d'exécutable
su - # fournir le mot de passe de root
cd /tmp
strace -s80 -onom_programme.root.trace nom_d'exécutable
diff nom_programme.user.trace nom_programme.root.trace | tail -50
Attention : ne pas utiliser "chmod" et "chown" n'importe comment afin d'éviter d'abaisser toutes les protections du système.
Exemple d'utilisation de "strace" (les commentaires apparaissent précédés d'un signe dièse) :
su - # passer root
cd /tmp
touch fichier_sans_interet
chown root.root fichier_sans_interet
chmod g=,o= fichier_sans_interet
strace -s80 -oessai_root.tmp cat fichier_sans_interet
chmod a+r essai_root.tmp
exit # retour sous un compte utilisateur non privilégié
cd /tmp
strace -s80 -oessai_user.tmp cat fichier_sans_interet
# le message d'erreur apparaît, il est facile à comprendre. mais
# comportons-nous comme si "cat" n'en produisait pas ...
diff essai_user.tmp essai_root.tmp | tail -50
< open("fichier_sans_interet", O_RDONLY) = -1 EACCES (Permission denied)
fichier_sans_interet en mode "lecture seule"
(O_RDONLY : Open ReaD-ONLY) et que le système refusa
et renvoya un code de retour -1 (permissions inadéquates).
L'option -f, grâce à laquelle strace piste tous les
processus créés par le programme examiné, s'avère souvent utile.
strace peut aussi « espionner » un processus actif grâce à son
option -p. Pour aller plus loin utiliser
ltrace.
Installer la plus récente version du logiciel.
Consulter le site Web "home" du logiciel. La documentation contient souvent son URL.
Chercher de l'information sur l'Internet et Usenet grâce aux robots de recherche, en fournissant des mots-clés spécifiques. Les utilisateurs de Red Hat pourront mettre helptool à contribution.
Pourquoi, si vous connaissez un peu le langage utilisé par les développeurs du programme, ne pas essayer de déterminer la cause du problème ?
CFLAGS du
Makefile. En cas de crash violent (message Segmentation fault)
autoriser la production de fichiers core grâce à ulimit -c
0 (explications : chercher ulimit dans le man de bash), faire
crasher la version compilée en mode debug, invoquer 'gdb nomdubinaire
core', puis utiliser la commande 'where'.
En désespoir de cause il faudra poster un article Usenet afin de demander de l'aide.