Rechercher
SupportConsoleDéveloppeursCommencer un essaiContact

3.3. Enregistrement des interactions avec les applications

download PDF

Le code exécutable des applications interagit avec le code du système d'exploitation et les bibliothèques partagées. L'enregistrement d'un journal d'activité de ces interactions peut fournir suffisamment d'informations sur le comportement de l'application sans déboguer le code réel de l'application. Par ailleurs, l'analyse des interactions d'une application peut aider à identifier les conditions dans lesquelles un bogue se manifeste.

3.3.1. Outils utiles pour l'enregistrement des interactions avec les applications

Red Hat Enterprise Linux propose plusieurs outils pour analyser les interactions d'une application.

stresse

L'outil strace permet principalement d'enregistrer les appels système (fonctions du noyau) utilisés par une application.

  • L'outil strace peut fournir un résultat détaillé sur les appels, car strace interprète les paramètres et les résultats en connaissant le code du noyau sous-jacent. Les nombres sont transformés en noms de constantes respectifs, les drapeaux combinés par bit sont développés en liste de drapeaux, les pointeurs vers les tableaux de caractères sont déréférencés pour fournir la chaîne de caractères actuelle, et plus encore. La prise en charge des fonctionnalités plus récentes du noyau peut être insuffisante.
  • Vous pouvez filtrer les appels tracés pour réduire la quantité de données capturées.
  • L'utilisation de strace ne nécessite aucune configuration particulière, si ce n'est la mise en place du filtre de journalisation.
  • Tracer le code de l'application avec strace entraîne un ralentissement significatif de l'exécution de l'application. Par conséquent, strace n'est pas adapté à de nombreux déploiements de production. Comme alternative, envisagez d'utiliser ltrace ou SystemTap.
  • La version de strace disponible dans Red Hat Developer Toolset peut également altérer les appels système. Cette capacité est utile pour le débogage.
ltrace

L'outil ltrace permet d'enregistrer les appels de l'espace utilisateur d'une application vers des objets partagés (bibliothèques dynamiques).

  • L'outil ltrace permet de tracer les appels à n'importe quelle bibliothèque.
  • Vous pouvez filtrer les appels tracés pour réduire la quantité de données capturées.
  • L'utilisation de ltrace ne nécessite aucune configuration particulière, si ce n'est la mise en place du filtre de journalisation.
  • L'outil ltrace est léger et rapide, et offre une alternative à strace: il est possible de tracer les interfaces respectives dans des bibliothèques telles que glibc avec ltrace au lieu de tracer les fonctions du noyau avec strace.
  • Étant donné que ltrace ne gère pas un ensemble connu d'appels comme strace, il ne tente pas d'expliquer les valeurs transmises aux fonctions de la bibliothèque. La sortie de ltrace ne contient que des nombres bruts et des pointeurs. L'interprétation de la sortie ltrace nécessite la consultation des déclarations d'interface des bibliothèques présentes dans la sortie.
Note

Dans Red Hat Enterprise Linux 9, un problème connu empêche ltrace de tracer les fichiers exécutables du système. Cette limitation ne s'applique pas aux fichiers exécutables créés par les utilisateurs.

SystemTap

SystemTap est une plateforme d'instrumentation permettant de sonder les processus en cours d'exécution et l'activité du noyau sur le système Linux. SystemTap utilise son propre langage de script pour programmer des gestionnaires d'événements personnalisés.

  • Par rapport à l'utilisation de strace et ltrace, la création de scripts d'enregistrement implique plus de travail lors de la phase d'installation initiale. Cependant, les capacités de script étendent l'utilité de SystemTap au-delà de la simple production de journaux.
  • SystemTap fonctionne en créant et en insérant un module dans le noyau. L'utilisation de SystemTap est efficace et ne crée pas de ralentissement significatif du système ou de l'exécution de l'application en soi.
  • SystemTap est accompagné d'une série d'exemples d'utilisation.
GDB

Le débogueur GNU (GDB) est principalement destiné au débogage et non à l'enregistrement. Cependant, certaines de ses fonctionnalités le rendent utile même dans le cas où l'interaction d'une application est la principale activité d'intérêt.

  • Avec GDB, il est possible de combiner facilement la capture d'un événement d'interaction avec le débogage immédiat du chemin d'exécution qui s'ensuit.
  • La GDB est mieux adaptée à l'analyse de la réponse à des événements peu fréquents ou singuliers, après l'identification initiale d'une situation problématique par d'autres outils. L'utilisation de la BDG dans un scénario avec des événements fréquents devient inefficace, voire impossible.

Ressources supplémentaires

3.3.2. Contrôler les appels système d'une application avec strace

L'outil strace permet de surveiller les appels système (noyau) effectués par une application.

Conditions préalables

  • Vous devez avoir installé strace sur le système.

Procédure

  1. Identifier les appels système à surveiller.

  2. Lancez strace et joignez-le au programme.

    • Si le programme que vous voulez surveiller n'est pas en cours d'exécution, lancez strace et indiquez l'adresse program: 

      $ strace -fvttTyy -s 256 -e trace=call program

    • Si le programme est déjà en cours d'exécution, recherchez son identifiant de processus (pid) et attachez-y strace: 

      $ ps -C program
(...)
$ strace -fvttTyy -s 256 -e trace=call -ppid
    • Remplacez call par les appels système à afficher. Vous pouvez utiliser l'option -e trace=call plusieurs fois. Si elle n'est pas remplacée, strace affichera tous les types d'appels système. Voir la page de manuel strace(1) pour plus d'informations.
    • Si vous ne souhaitez pas suivre les processus ou les threads qui ont fait l'objet d'une bifurcation, n'utilisez pas l'option -f.

  3. L'outil strace affiche les appels système effectués par l'application et leurs détails.

    Dans la plupart des cas, une application et ses bibliothèques effectuent un grand nombre d'appels et la sortie strace apparaît immédiatement, si aucun filtre pour les appels système n'est défini.

  4. L'outil strace se termine lorsque le programme se termine.

    Pour mettre fin à la surveillance avant que le programme suivi ne se termine, appuyez sur Ctrl C.

    • Si strace a démarré le programme, celui-ci se termine en même temps que strace.
    • Si vous avez joint strace à un programme déjà en cours d'exécution, le programme se termine en même temps que strace.

  5. Analyser la liste des appels système effectués par l'application.

    • Les problèmes d'accès ou de disponibilité des ressources sont signalés dans le journal par des appels renvoyant des erreurs.
    • Les valeurs transmises aux appels système et les modèles de séquences d'appels permettent de comprendre les causes du comportement de l'application.
    • Si l'application se bloque, les informations importantes se trouvent probablement à la fin du journal.
    • Le résultat contient beaucoup d'informations inutiles. Cependant, vous pouvez construire un filtre plus précis pour les appels système qui vous intéressent et répéter la procédure.
Note

Il est avantageux de voir la sortie et de l'enregistrer dans un fichier. Pour ce faire, utilisez la commande tee: 

$ strace ... |& tee your_log_file.log

Ressources supplémentaires

3.3.3. Contrôler les appels de fonctions de la bibliothèque d'une application avec ltrace

L'outil ltrace permet de surveiller les appels d'une application à des fonctions disponibles dans des bibliothèques (objets partagés).

Note

Dans Red Hat Enterprise Linux 9, un problème connu empêche ltrace de tracer les fichiers exécutables du système. Cette limitation ne s'applique pas aux fichiers exécutables créés par les utilisateurs.

Conditions préalables

  • Vous devez avoir installé ltrace sur le système.

Procédure

  1. Identifiez les bibliothèques et les fonctions qui vous intéressent, si possible.

  2. Lancez ltrace et joignez-le au programme.

    • Si le programme que vous souhaitez surveiller n'est pas en cours d'exécution, lancez ltrace et indiquez program: 

      $ ltrace -f -l library -e function program

    • Si le programme est déjà en cours d'exécution, recherchez son identifiant de processus (pid) et attachez-y ltrace: 

      $ ps -C program
(...)
$ ltrace -f -l library -e function program -ppid

    • Utilisez les options -e, -f et -l pour filtrer les résultats :

      • Fournir les noms des fonctions à afficher sous la forme function. L'option -e function peut être utilisée plusieurs fois. Si elle est omise, ltrace affiche les appels à toutes les fonctions.
      • Au lieu de spécifier des fonctions, vous pouvez spécifier des bibliothèques entières avec l'option -l library pour spécifier des bibliothèques entières. Cette option se comporte de la même manière que l'option -e function cette option se comporte de la même manière que l'option
      • Si vous ne souhaitez pas suivre les processus ou les threads qui ont fait l'objet d'une bifurcation, n'utilisez pas l'option -f.

      Voir la page du manuel ltrace(1)_ pour plus d'informations.

  3. ltrace affiche les appels à la bibliothèque effectués par l'application.

    Dans la plupart des cas, une application effectue un grand nombre d'appels et la sortie ltrace s'affiche immédiatement, si aucun filtre n'est défini.

  4. ltrace se termine lorsque le programme se termine.

    Pour mettre fin à la surveillance avant que le programme suivi ne se termine, appuyez sur ctrl C.

    • Si ltrace a démarré le programme, celui-ci se termine en même temps que ltrace.
    • Si vous avez joint ltrace à un programme déjà en cours d'exécution, le programme se termine en même temps que ltrace.

  5. Analyser la liste des appels à la bibliothèque effectués par l'application.

    • Si l'application se bloque, les informations importantes se trouvent probablement à la fin du journal.
    • Le résultat contient beaucoup d'informations inutiles. Cependant, vous pouvez construire un filtre plus précis et répéter la procédure.
Note

Il est avantageux de voir la sortie et de l'enregistrer dans un fichier. Pour ce faire, utilisez la commande tee: 

$ ltrace ... |& tee your_log_file.log

Ressources supplémentaires

  • La page du manuel ltrace(1): 

    $ man ltrace
  • Guide de l'utilisateur de Red Hat Developer Toolset - Chapitre ltrace

3.3.4. Contrôler les appels système d'une application avec SystemTap

L'outil SystemTap permet d'enregistrer des gestionnaires d'événements personnalisés pour les événements du noyau. Par rapport à l'outil strace, il est plus difficile à utiliser mais plus efficace et permet une logique de traitement plus complexe. Un script SystemTap appelé strace.stp est installé avec SystemTap et fournit une approximation de la fonctionnalité de strace en utilisant SystemTap.

Conditions préalables

  • SystemTap et les paquets de noyau respectifs doivent être installés sur le système.

Procédure

  1. Recherchez l'ID du processus (pid) du processus que vous souhaitez surveiller : 

    $ ps -aux

  2. Exécutez SystemTap avec le script strace.stp: 

    # stap /usr/share/systemtap/examples/process/strace.stp -x pid

    La valeur de pid est l'identifiant du processus.

    Le script est compilé dans un module du noyau, qui est ensuite chargé. Cela introduit un léger délai entre la saisie de la commande et l'obtention de la sortie.

  3. Lorsque le processus effectue un appel système, le nom de l'appel et ses paramètres sont imprimés sur le terminal.
  4. Le script se termine lorsque le processus se termine ou lorsque vous appuyez sur Ctrl C.

3.3.5. Utilisation de GDB pour intercepter les appels système des applications

Le débogueur GNU (GDB) vous permet d'arrêter l'exécution d'un programme dans diverses situations. Pour arrêter l'exécution lorsque le programme effectue un appel système, utilisez une commande GDB catchpoint.

Conditions préalables

  • Vous devez comprendre l'utilisation des points d'arrêt GDB.
  • GDB doit être attaché au programme.

Procédure

  1. Fixer le point d'inflexion : 

    (gdb) catch syscall syscall-name

    La commande catch syscall définit un type spécial de point d'arrêt qui interrompt l'exécution lorsque le programme effectue un appel système.

    L'option syscall-name spécifie le nom de l'appel. Vous pouvez spécifier plusieurs points de capture pour différents appels système. L'omission de l'option syscall-name permet à GDB de s'arrêter sur n'importe quel appel système.

  2. Lancer l'exécution du programme.

    • Si le programme n'a pas commencé à s'exécuter, démarrez-le : 

      (gdb) r

    • Si l'exécution du programme est interrompue, reprenez-la : 

      (gdb) c
  3. GDB interrompt l'exécution après que le programme a exécuté un appel système spécifié.

Ressources supplémentaires

3.3.6. Utilisation de GDB pour intercepter la gestion des signaux par les applications

Le débogueur GNU (GDB) vous permet d'arrêter l'exécution dans diverses situations qui surviennent au cours de l'exécution du programme. Pour arrêter l'exécution lorsque le programme reçoit un signal du système d'exploitation, utilisez une commande GDB catchpoint.

Conditions préalables

  • Vous devez comprendre l'utilisation des points d'arrêt GDB.
  • GDB doit être attaché au programme.

Procédure

  1. Fixer le point d'inflexion : 

    (gdb) signal de capture signal-type

    La commande catch signal définit un type spécial de point d'arrêt qui interrompt l'exécution lorsqu'un signal est reçu par le programme. L'option signal-type spécifie le type de signal. Utilisez la valeur spéciale 'all' pour capturer tous les signaux.

  2. Laissez le programme s'exécuter.

    • Si le programme n'a pas commencé à s'exécuter, démarrez-le : 

      (gdb) r

    • Si l'exécution du programme est interrompue, reprenez-la : 

      (gdb) c
  3. GDB interrompt l'exécution après que le programme a reçu un signal spécifié.

Ressources supplémentaires

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.