22.4. Détection de problèmes logiciels

Le service abrt-ccpp installe son propre gestionnaire core-dump, qui, lorsque démarré, remplace la valeur par défaut de la variable core_pattern du noyau, afin que les incidents C et C++ soient gérés par abrtd. Si vous arrêtez le service abrt-ccpp, l'ancienne valeur de core_pattern sera réintégrée.

Par défaut, le fichier /proc/sys/kernel/core_pattern contient la chaîne core, ce qui signifie que le noyau produit des fichiers avec le préfixe core. dans le répertoire actuel du processus en panne. Le service abrt-ccpp remplace le fichier core_pattern afin qu'il contienne la commande suivante :

|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e

This command instructs the kernel to pipe the core dump to the abrt-hook-ccpp program, which stores it in ABRT's dump location and notifies the abrtd daemon of the new crash. It also stores the following files from the /proc/PID/ directory (where PID is the ID of the crashed process) for debugging purposes: maps, limits, cgroup, status. See proc(5) for a description of the format and the meaning of these files.

Le paquet abrt-addon-python installe un gestionnaire d'exceptions personnalisé pour les applications Python. L'interprète Python importe ensuite automatiquement le fichier abrt.pth installé dans /usr/lib64/python2.7/site-packages/, qui importera à son tour le fichier abrt_exception_handler.py. Ceci remplace le fichier Python par défaut sys.excepthook par un gestionnaire personnalisé, qui transfère les exceptions non gérées au démon abrtd via son API Socket.

Pour désactiver l'importation automatique de modules spécifiques aux sites, et empêcher ainsi le gestionnaire d'exceptions personnalisé ABRT d'être utilisé lors de l'exécution d'une application Python, veuillez passer l'option -S à l'interprète Python :

~]$ python -S file.py

Dans la commande ci-dessus, remplacez file.py par le nom du script Python que vous souhaitez exécuter sans utilisation de modules spécifiques aux sites.

Le paquet rubygem-abrt enregistre un gestionnaire personnalisé en utilisant la fonctionnalité at_exit, qui est exécutée lorsqu'un programme se termine. Ceci permet de vérifier les exceptions non gérées possibles. Chaque fois qu'une exception non gérée est capturée, le gestionnaire ABRT prépare un rapport de bogue, qui pourra être soumis à Red Hat Bugzilla à l'aide des outils ABRT standard.

Le Connector Java ABRT est un agent JVM qui rapporte les exceptions Java non interceptées au démon abrtd. L'agent enregistre plusieurs rappels d'événement JVMTI et doit être chargé dans JVM à l'aide du paramètre de ligne de commande -agentlib. Remarquez que le traitement des rappels enregistrés affecte négativement les performances de l'application. Pour intercepter les exceptions ABRT d'une classe Java, veuillez utiliser la commande suivante :

~]$ java -agentlib:abrt-java-connector[=abrt=on] $MyClass -platform.jvmtiSupported true

Dans la commande ci-dessus, remplacez $MyClass par le nom de la classe Java que vous souhaitez tester. En passant l'option abrt=on au connecteur, vous vous assurez que les exceptions sont gérées par abrtd. Dans le cas où vous souhaiteriez faire en sorte que le connecteur fasse sortir les exceptions sur la sortie standard, ne pas utiliser cette option.

Le service abrt-xorg collecte et traite les informations sur les incidents du serveur X.Org server qui proviennent du fichier /var/log/Xorg.0.log. Remarquez qu'aucun rapport n'est généré si un module X.org sur liste noire est chargé. À la place, un fichier not-reportable est créé dans le répertoire de données problématiques avec une explication appropriée. Vous trouverez la liste des modules fautifs dans le fichier /etc/abrt/plugins/xorg.conf. Seuls les modules de pilotes graphiques propriétaires sont mis sur liste noire par défaut.

En vérifiant la sortie des journaux de noyau, ABRT est capable d'intercepter et de traiter les oops de noyau (« Kernel Oops ») — des déviations non fatales du comportement par défaut du noyau Linux. Cette functionalité est fournie par le service abrt-oops.

ABRT peut également détecter et traiter les paniques de noyau — des erreurs fatales, et non récupérables qui nécessitent un redémarrage à l'aide du service abrt-vmcore. Le service démarre uniquement lorsqu'un fichier vmcore (un fichier d'image mémoire noyau) apparaît dans le répertoire /var/crash/. Lorsqu'un fichier d'image mémoire est trouvé, abrt-vmcore crée un nouveau répertoire de données problématiques dans le répertoire /var/tmp/abrt/ et déplace le fichier de l'image mémoire sur le nouveau répertoire de données problématiques créé. Une fois la recherche du répertoire /var/crash/ est terminée, le service est arrêté.

Pour qu'ABRT soit capable de détecter une panique de noyau, le service kdump doit être activé sur le système. La quantité de mémoire réservée au noyau kdump doit être définie correctement. Cela peut être effectué en utilisant l'outil graphique system-config-kdump ou en spécifiant le paramètre crashkernel dans la liste des options de noyau dans le menu GRUB. Pour obtenir des détails sur la manière d'activer et de configurer kdump, veuillez consulter le Guide de vidage sur incident noyau Red Hat Enterprise Linux 7. Pour obtenir des informations sur la façon d'apporter des modifications au menu GRUB, voir Chapitre 24, Utiliser le chargeur de démarrage GRUB 2.

En utilisant le service abrt-pstoreoops, ABRT est capable de collecter et de traiter des informations sur les paniques de noyau, qui, sur les systèmes prenant en charge pstore, sont stockées dans le répertoire monté automatiquement /sys/fs/pstore/. L'interface pstore (stockage persistant) dépendante de la plateforme, fournit un mécanisme de stockage de données à travers les redémarrages système, permettant ainsi de préserver les informations sur les paniques de noyau. Le service démarre automatiquement lorsque les fichiers de vidage sur incident du noyau apparaissent dans le répertoire /sys/fs/pstore/.