Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

22.4. Détection de problèmes logiciels

ABRT est capable de détecter, analyser et traiter les incidents d'applications écrites dans divers langages de programmation. De nombreux paquets offrant la prise en charge de détection d'incidents divers sont installés automatiquement lorsque l'un des paquets principaux ABRT (abrt-desktop, abrt-cli) est installé. Veuillez consulter la Section 22.2, « Installer ABRT et lancer ses services » pour obtenir des instructions sur la manière d'installer ABRT. Veuillez consulter le tableau ci-dessous pour obtenir une liste des types d'incidents pris en charge et de leurs paquets respectifs.

Tableau 22.2. Langages de programmation et projets logiciels pris en charge

Langage/projetPaquet
C ou C++abrt-addon-ccpp
Pythonabrt-addon-python
Rubyrubygem-abrt
Javaabrt-java-connector
X.Orgabrt-addon-xorg
Linux (oops de noyau)abrt-addon-kerneloops
Linux (panique de noyau)abrt-addon-vmcore
Linux (stockage persistant)abrt-addon-pstoreoops

22.4.1. Détection d'incidents C et C++

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.

22.4.2. Détection des exceptions Python

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.

22.4.3. Détection des exceptions Ruby

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.

22.4.4. Détection des exceptions Java

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.

22.4.5. Détection d'incidents X.Org

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.

22.4.6. Détection d'oops et de paniques de noyau

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/.