A réaliser par binôme. Le travail à réaliser est composé de quatre parties.

Transcription

1 ROJET RCHITECTURE Titre : OUTILS POUR LE DIAGNOSTIC SUR UN SYSTÈME LINUX A réaliser par binôme. Le travail à réaliser est composé de quatre parties. Une machine virtuelle Ubuntu avec tous les outils dont vous avez besoin est fournie. Il est conseillé de travailler avec cette machine virtuelle et d'utiliser VirtualBox by Oracle ( sur Mac/Windows/Linux pour la lancer. ARECAR nsary Projet réalisé par ALI ASIC, DIRIL NOEL, MARECAR ANSARY tous étudiant en informatique.

2 Partie 1 : tester les performances du disque 1.1 L'outil bonnie++ Il s'agit d'un utilitaire qui effectue des tests de performance de votre système de fichiers. Dans un système de fichiers, on y écrit et on y lit. Ces opérations peuvent être effectuées de manière séquentielle, octet par octet ou par blocs de tailles fixes. On peut aussi être amené à lire (dans un fichier) de manière aléatoire, par exemple on lisant le premier octet puis le 1000ème puis le 50ème etc. Ces différentes donnent d'accès impactent sur les performances que l'on peut obtenir c est à dire sur le nombre de kb/s que l'on peut attendre. On observe généralement que les méthodes séquentielles sont plus performantes (en terme de kb/s) que les accès aléatoires par exemple. Nous allons vous demander d'observer, grâce à bonnie++, des performances du système de fichiers, et selon différents schémas d'accès.. Exemple d'un test bonnie++ #./bonnie++ -u root Using uid:0, gid:0. Writing with putc()...done Writing intelligently...done Rewriting...done Reading with getc()...done Reading intelligently...done start 'em...done...done...done... Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...done. Create files in random order...done. Stat files in random order...done. Delete files in random order...done. Version 1.03d Sequential Output Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP localhost 300M Sequential Create Random Create Create-- --Read--- -Delete-- -Create-- --Read--- -Delete files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP localhost,300m,6000,40,5913,9,4213,10,10407,86,20664,20,1078.1,13,16,10,93,+++++,+++,74,63,1 7,90,+++++,+++,27,58 La dernière ligne est au format CSV (c'est un format pour tableurs comme Exel ou Calc de Libreoffice)

3 Questions Quelle est la taille du fichier qui a été utilisée dans le précédent exemple? (Hint : lire la page du manuel de bonnie++) D'après la page de manuel de bonnie++, on remarque que la taille du fichier du précédent exemple est de 300Mo. Lancer la commande précédente dans votre machine virtuelle Ubuntu. c) Interpréter la dernière ligne de l'exemple précédent i.e. les résultats expérimentaux du point b) (à quoi correspondent les valeurs obtenues) La dernière ligne est au format CSV (c'est un format pour tableurs comme Exel ou Calc de Libreoffice). La dernière ligne nous donne des informations sur la vitesse de lecture (en K/sec) et du pourcentage du processus utilisé pour chaque sortie (input/output). 3000M Correspond à la taille du fichier utilisé pour le test Ecriture du fichier 6000 Par caractère, Bonnie a enregistré une vitesse de sortie de 80 K /seconde. 40 Ce travail a consommé 99% du temps du CPU. Lecture du fichier 5913 Par caractère, Bonnie a enregistré une vitesse d'entrée de 549 k/s 9 Ce travail a consommé 99% du temps du CPU Processus de recherche 4213 Le processus de recherche aléatoire à durée sec 10 Ce processus a utilisé 228% du temps du CPU Files 16 Le système indique la présence de 16 fichiers (ou pas) Création séquentielle La création séquentielle a duré sec et a demandé 81% du temps du CPU C est le temps que le système a pris lors de la suppression des fichiers et cela a demandé 75% du temps du CPU Création aléatoire La création séquentielle a duré sec et a demandé 81% du temps du CPU C est le temps que le système a pris lors de la suppression des fichiers et cela a demandé 75% du temps du CPU

4 Les résultats suivant sont autres que les temps de latences pour chacun des processus. d) Relancer un test pour évaluer les performances du répertoire /tmp Qu'observez-vous? bonnie++ -d tmp -u root -s300 -r2 Normalement votre HOME directory correspond à un disque qui est sur le réseau et /tmp un répertoire qui est physiquement attaché à votre machine. Nous devrions obtenir des performances différentes car généralement, accéder à un disque réseau coûte "plus cher" qu'accéder à une partition locale. e) Montez une clé USB (attention, cela peut être technique de rendre visible cette clé à la machine virtuelle) et refaite un test pour évaluer les performances de la clé USB. On peut voir que les résultats au niveau des différentes vitesses enregistrées sont beaucoup moins bons puisque le test a été effectué sur une clé USB qui n'appartient donc pas physiquement à la machine. En revanche on peut voir que le travail du CPU est moins important que sur les précédents tests. f) Faites une synthèse de tous les résultats expérimentaux. On peut apercevoir que les tests sur le HOME directory et sur le répertoire /tmp ont des résultats qui sont assez proche mais diffèrent, cependant le test sur la clef USB présente des résultats bien plus faibles.

5 1.2 L'outil sysstat On veut comparer les résultats expérimentaux fournis par bonnie++ avec ceux qui sont fournis par les outils Sysstat ( Sysstat est en faîte un ensemble de programmes qui permet non seulement de récupérer de l'information sur les performances des disques mais aussi sur les performances du processeur, de la mémoire, du réseau. Avant toute chose, faites un man iostat et un man pidstat qui sont les deux outils étudiés. a) Première expérimentation : L'outil sysstat a)./iostat (PASS1)./bonnie++ -u root./iostat (PASS2) Meilleur rapidité d ecriture et de lecture que sur PASS1 les 2 valeurs en correspojndent pas b)./pidstat -d

6

7 ./bonnie++ -u root

8 ./pidstat -d On observe que lors de notre deuxième lancement de pidstat les différents processus prennent plus de RAM

9 Partie 2 : débogage avec ddd Un débogueur (ou débogueur, de l'anglais debugger) est un logiciel qui aide un développeur à analyser les bugs d'un programme. Pour cela, il permet d'exécuter le programme pas-à-pas, d'afficher la valeur des variables à tout moment, de mettre en place des points d'arrêt sur des conditions ou sur des lignes du programme... Les outils installés dans votre machine virtuelle Ubuntu sond ddd (outil graphique), gdb et lldb (outils en mode texte). On lance ddd en tapant ddd sous le prompt Linux. Le programme C que l'on va tracer doit avoir été compilé avec l'option -g (g comme debugging), sinon il ne sera pas possible de travailler avec ces outils. La grande majorité des débogueurs offrent des fonctionnalités similaires à celles qui suivent : a) Outils pour stopper (mettre en pause) l'exécution du programme o commande d'arrêt manuel : le programmeur peut décider à tout moment de stopper l'exécution o point d'arrêt : placé à un endroit spécifique du programme (généralement dans le code source), il indique au débogueur d'arrêter l'exécution lorsqu'elle atteindra cet endroit o point d'arrêt conditionné : comme le point d'arrêt, mais avec une condition supplémentaire (comme le nombre de passages sur ce point d'arrêt par exemple) o point d'observation (watch) : permet d'arrêter l'exécution du programme sur la condition de la modification d'une variable b) Outils pour piloter l'exécution du programme o pas-à-pas : exécution instruction par instruction o pas-à-pas sommaire : une instruction est exécutée, dans le programme principal, à chaque fois que le programmeur le demande o pas-à-pas détaillé : comme le pas-à-pas sommaire, sauf que le pas-à-pas entre aussi dans les fonctions o avec cadencement : à intervalles périodiques, une instruction est exécutée (cela permet de ralentir l'exécution du programme afin qu'elle puisse être suivie de près par l'œil humain) o redémarrage de la fonction courante (drop frame) : abandon de l'exécution actuelle de la fonction courante et démarrage d'une nouvelle exécution de la fonction courante o retour en arrière : revenir à l'instruction précédente, en retrouvant l'état précédent (fonctionnalité assez rare) c) Outils pour observer l'état du programme o observation d'une variable o observation d'une zone mémoire o observation d'un registre du microprocesseur o observation de la pile d'appel (backtrace) o observation du code source avec point d'exécution actuel o observation du code assembleur (sauf langage interprété) avec point d'exécution actuel o trace : permet d'observer des informations en différé, sans stopper l'exécution du programme En outre, le débogueur permet généralement de modifier l'état du programme, lorsque son exécution est stoppée : o modification d'un registre o modification d'une variable o modification d'une zone mémoire Votre travail : nous allons travailler sur le code source td09.c qui est dans le répertoire M2101.

10 Questions : Ce programme comporte des erreurs. Essayez de les repérez, ne les corrigez pas. Le but de ce programme est de remplir un tableau avec des valeurs, puis de faire des modifications de ces valeurs (multiplier par deux, puis ajouter 1). Check list : o Compilez le programme, et exécutez-le avec le débogueur ddd. Le listing du programme doit s'afficher. o Commencez, avant de faire tourner le programme par insérer un point d'arrêt au début du main, un point d'arrêt dans la toute première boucle, un point d'arrêt dans la fonction fact.

11 o Faites afficher la fenêtre de données de ddd. En faisant un clic droit, faites afficher toutes les variables du programme. Que se passe-t-il si on essaye d'afficher NUM? NUM a été déffinie au début du programme et doit retourner 6. Or dans ce cas ce n es pas cela! Que remarque-t-on quand on essaye d'afficher la variable i de la fonction fact?

12 La valeur de i retourner depend de l'endroit ou on demande de l'afficher. o Remarquez la différence d'affichage entre b et c. À quoi cela peut-il être dû?

13 L un est un tableau mais un tableau est un pointeur. L autre est uniquement un pointeur. o Dans un terminal, testez le programme. Vérifiez qu'il ne fonctionne pas. Il ne fonctionne pas o Commencez l'exécution du programme (bouton run ou menu équivalent). Après le premier arrêt, utilisez le bouton step pour avancer pas à pas dans le programme. Regardez évoluer peu à peu les valeurs des variables. Que remarque-t-on sur la valeur affichée de i lorsqu'on rentre dans l'évaluation de la fonction fact? Le i du main est stoppé et le i de la fonction débute à 12 puis et puis problème dans la boucle de la fonction. (i=n au lieu de i<=n). o Quelle est la première erreur? Corrigez-là, recompilez (de l'intérieur du débogueur, avec le bouton make).

14 Les entiers du main sont à l extérieur. Dans fact et dans sa boucle il est mis i=n or c est tant que i<=n. o Refaites une exécution pas-à-pas. Vérifiez que la fonction renvoie maintenant la bonne valeur. Que constate-t-on dans l'affichage du tableau b? Trouvez la deuxième erreur. La valeur ne change pas o Faites afficher en partant de la zone de données le contenu pointé par c. Quelle est la troisième erreur? Corrigez-la. «*c=b;» o Quelle est l'adresse du premier élément du tableau b? o Surveillez pas-à-pas l'exécution de la deuxième boucle du programme (qui multiplie par 2). Que remarque-t-on sur le tableau b? Expliquez. A compelter c[i] va prendre la valeur d elle-même multiplié par 2 tant que i est inférieur à 6.

15 o Il serait plus simple de faire afficher c comme un tableau de 6 éléments. Utilisez la syntaxe donnée dans le cours pour le faire. Vérifiez que les valeurs sont changées aussi bien dans c que dans b. o La dernière boucle utilise l'arithmétique des pointeurs : un pointeur (c) change de valeur et pointe tour à tour. Elle comporte une erreur. Trouvez-la et corrigez-la o Est-il correct d'affecter une valeur à *d? Pourquoi? Bonus Pour celles et ceux qui veulent aller plus loin... o Réécrivez le programme précédent en faisant de b non pas un tableau statique, mais un tableau alloué dynamiquement. N'oubliez pas de libérer l'espace mémoire à la fin du tableau. o Est-il possible de lire dans ce tableau après avoir libéré la mémoire? o Après avoir libéré la mémoire (à la fin du programme), créez un nouveau tableau d'entiers (de taille similaire mais pas identique). Que constate-t-on?

16 Partie 3 : tester les performances du processeur Performance Application Programming Interface (PAPI) est une interface portable (sous la forme d'une librairie) vers les compteurs de performance des processeurs. Un compteur de performance est un dispositif matériel (du silicium) dédié à l'observation de certains évènements de très bas niveau (internes au processeur). Il peut s'agir du nombre d'instructions réellement exécutées, du nombre de défaut de caches... L'intérêt des compteurs de performance est d'être une méthode d'observation non intrusive parce qu'elle est assurée au niveau matérielle et pas au niveau logiciel. Certains processeurs font de l'exécution spéculative c est à dire que pour exécuter une conditionnelle ils choisissent d'exécuter la branche pour laquelle la condition est vérifiée... Mais quand le processeur détecte que la condition est fausse en réalité, alors le processeur arrête l'instruction précédente pour exécuter la branche pour laquelle la condition est fausse. Ainsi, toute instruction qui commence... n'aboutit pas forcément. Les compteurs de performance permettent d'observer ce phénomène. Le monitoring de certains évènements permet de corréler la structure du code c est à dire d'estimer l'efficacité de la mise en correspondance de ce code avec l'architecture. Le fichier que l'on étudie est le fichier papi.c qui se trouve dans le répertoire M2101. Votre travail : a) Faites un commentaire de cet exemple de base qui montre comment utiliser l'interface de haut niveau de PAPI Cet exemple nous permet de se familiariser avec les fonctions de PAPI comme par exemple s'arrêter sur un ensemble d'évènement ou encore compter et lire les instructions ainsi que les cycles lors de ces évènements. -Au départ (l 37) déclaration et initialisation de notre ensemble d'évènements, La première fonction utilisée (l 53 : PAPI_library_init) initialise la bibliothèque et compare le numéro de version du fichier d'entête à la version de la bibliothèque, Si les 2 numéros ne sont pas compatibles la variable retval stock la trace du numéro et nous nous retrouvons donc avec une erreur dans le programme -Ensuite la seconde fonction PAPI_num_counters renvoie la longueur maximale du tableau de valeurs pour les fonctions de haut niveau. Cette valeur équivaut au nombre de compteurs de performances gérer par le système. -Si le programme ne retourne pas d erreur pendant la lecture de l'évènement alors il lit le nombre d'instructions exécutées et de cycles utilisés pour l'évènement sélectionné (ici l'addition (l 89)) grâce à une autre fonction qui est PAPI_read_counters) -Ensuite le programme lance la fonction PAPI_accum_counters (l 102) qui permet d'accumuler les valeurs des compteurs avec les valeurs dans le tableau, avant de réinitialiser ces compteurs. -Pour finir, le programme lance la fonction PAPI_stop_counters (l 114) qui permet de lire puis arrêter les compteurs. Dans notre cas le programme lit le nombre d'instructions exécutées et le nombre de cycles utilisés pour des multiplications.

17 b) Quels sont les résultats? gcc -Wall papi.c -lpapi &&./sorti.out Que signifient-ils? Le lancement du programme nous permet de savoir que le système possède 5 compteurs de performances. Pour le premier évènement (additions), le programme a enregistré instructions executées, et cycles utilisés. c) Faites une série d'expériences en modifiant la valeur de la constante THRESHOLD, par exemple en doublant la valeur de celle-ci à chaque fois. Est-ce que les valeurs des compteurs de performance doublent à chaque fois? Non Pourquoi? Dans la consigne il est dit : «Certains processeurs font de l'exécution spéculative c est à dire que pour exécuter une conditionnelle ils choisissent d'exécuter la branche pour laquelle la condition est vérifiée... Mais quand le processeur détecte que la condition est fausse en réalité, alors le processeur arrête l'instruction précédente pour exécuter la branche pour laquelle la condition est fausse. Ainsi, toute instruction qui commence... n'aboutit pas forcément. Les compteurs de performance permettent d'observer ce phénomène.» d) Pour les binômes les plus avancés (question bonus), modifiez le code de papi.c pour observer les défauts de cache sur le cache L1. (Voir avec votre enseignant pour des explications complémentaires si besoin). Refaites les questions a) b) c). Performance Application Programming Interface (PAPI) est une interface de programmation portable (sous la forme d'une bibliothèque logicielle) permettant d'accéder aux compteurs matériels spécifiques aux microprocesseurs modernes. PAPI est utilisé pour collecter des informations de bas niveau (telles que le nombre d'opérations en virgule flottantes FLOPS par seconde, le nombre de cache misses durant l'exécution d'un code, etc..). PAPI est interfacé avec les systèmes d'exploitation de type UNIX. La bibliothèque PAPI est actuellement capable d'accéder les compteurs matériel de la plupart des processeurs modernes. La liste des processeurs non reconnu ne cesse de diminuer.

18 Partie 4 : surveiller les appels système avec strace strace est un outil de débogage sous Linux pour surveiller les appels système utilisés par un programme, et tous les signaux qu'il reçoit. L'utilisation la plus courante est de lancer un programme en utilisant strace, qui affiche une liste des appels système faits par le programme. Par exemple, utiliser strace peut révéler que le programme tente d'accéder à un fichier qui n'existe pas ou qui ne peut pas être lu. Une autre utilisation est d'utiliser l'option -p pour le rattacher à un programme lancé. C'est utile lorsqu'un programme ne répond plus, et peut révéler, par exemple, que le processus est bloqué car il attend de faire une connexion réseau. Comme strace ne détaille que les appels système, il ne peut pas être utilisé comme un débogueur de code, tel que Gdb. Il reste cependant plus simple à utiliser qu'un débogueur de code, et est un outil extrêmement utile pour les administrateurs système. Exemples concrets d'utilisation : > strace -Ff -tt <program> <arguments> 2>&1 tee strace-<program>.log qui va vous permettre de générer un fichier de log à partir duquel vous pourrez faire une analyse. > strace -Ff -tt -p <PID> 2>&1 tee strace-<program>.log qui va vous permettre de tracer un PID (process identifier) particulier. Votre travail : Compilez le programme suivant : #include <stdio.h> void main() { printf("hi\n"); }

19 Utiliser strace pour Lister tous les appels systèmes faits par votre programme. On tape sur le terminal : strace Ff tt test test est le nom de notre exécutable Quel est l'appel Système qui revient le plus? Pouvez-vous expliquer en quoi consiste cet appel Système (attention, c'est dur!)? L'appel système qui apparaît le plus souvent est mmap2(). Il permet d'établir une projection en mémoire des fichiers ou périphériques. Il est donc utilisé pour l'allocation de mémoire. Cet appel système sert juste a allouer un espace mémoire. Mmap 1 : Établir/supprimer une projection en mémoire (map/unmap) des fichiers ou des périphériques. L'appel système mmap2() réalise la même opération que mmap sauf que l'argument final spécifie un décalage dans le fichier en unité de 4096 octets plutôt qu'en octets comme cela est fait par mmap.

20 Compilez le programme suivant : #include <stdio.h> #include <unistd.h> void main() { int i; for(i=0;i<12;i++){ printf("hello there!\n"); sleep(1); printf("goodbye\n"); } } --Video--

21 Trouver l'option de strace qui va vous permettre d'observer le temps passé dans chaque appel système. Lancer strace avec cette option sur votre exemple et dites quel est l'appel Système qui prend le plus de temps -c : compte le temps, les appels et les erreurs pour chaque appelles système. -r : Sa permet d avoir pour chaque appel système le temps qu il a passé. On appelle cela en anglais le timestamp relatif. -T :temps passé pour chaque appels système. L'option qui permet d'observer le temps passé sur chaque appel est «-T». Soit celui qui prend le plus de temps est nanosleep. asc95@test:~/workspace $ gcc -Wall test.c -o t3 test.c:4:6: warning: return type of main is not int [-Wmain] void main () ^ asc95@test:~/workspace $ strace -T./t3

22 execve("./t3", ["./t3"], [/* 70 vars */]) = 0 < > brk(0) = 0x1b1b000 < > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) < > mmap(null, 8192, PROT_READ PROT_WRITE, MAP_PRIVATE MAP_ANONYMOUS, -1, 0) = 0x7f0c5e7f9000 < > access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) < > open("~/.c9/local/lib/tls/x86_64/libc.so.6", O_RDONLY O_CLOEXEC) = -1 ENOENT (No such file or directory) < > open("~/.c9/local/lib/tls/libc.so.6", O_RDONLY O_CLOEXEC) = -1 ENOENT (No such file or directory) < > open("~/.c9/local/lib/x86_64/libc.so.6", O_RDONLY O_CLOEXEC) = -1 ENOENT (No such file or directory) < > open("~/.c9/local/lib/libc.so.6", O_RDONLY O_CLOEXEC) = -1 ENOENT (No such file or directory) < > open("/etc/ld.so.cache", O_RDONLY O_CLOEXEC) = 3 < > fstat(3, {st_mode=s_ifreg 0644, st_size=59193,...}) = 0 < > mmap(null, 59193, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f0c5e7ea000 < > close(3) = 0 < > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) < > open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY O_CLOEXEC) = 3 < > read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\37\2\0\0\0\0\0"..., 832) = 832 < > fstat(3, {st_mode=s_ifreg 0755, st_size= ,...}) = 0 < > mmap(null, , PROT_READ PROT_EXEC, MAP_PRIVATE MAP_DENYWRITE, 3, 0) = 0x7f0c5e < > mprotect(0x7f0c5e3ce000, , PROT_NONE) = 0 < > mmap(0x7f0c5e5ce000, 24576, PROT_READ PROT_WRITE, MAP_PRIVATE MAP_FIXED MAP_DENYWRITE, 3, 0x1bb000) = 0x7f0c5e5ce000 < > mmap(0x7f0c5e5d4000, 17088, PROT_READ PROT_WRITE, MAP_PRIVATE MAP_FIXED MAP_ANONYMOUS, -1, 0) = 0x7f0c5e5d4000 < > close(3) = 0 < > mmap(null, 4096, PROT_READ PROT_WRITE, MAP_PRIVATE MAP_ANONYMOUS, -1, 0) = 0x7f0c5e7e9000 < > mmap(null, 8192, PROT_READ PROT_WRITE, MAP_PRIVATE MAP_ANONYMOUS, -1, 0) = 0x7f0c5e7e7000 < > arch_prctl(arch_set_fs, 0x7f0c5e7e7740) = 0 < > mprotect(0x7f0c5e5ce000, 16384, PROT_READ) = 0 < > mprotect(0x600000, 4096, PROT_READ) = 0 < > mprotect(0x7f0c5e7fb000, 4096, PROT_READ) = 0 < > munmap(0x7f0c5e7ea000, 59193) = 0 < > fstat(1, {st_mode=s_ifchr 0620, st_rdev=makedev(136, 1),...}) = 0 < > mmap(null, 4096, PROT_READ PROT_WRITE, MAP_PRIVATE MAP_ANONYMOUS, -1, 0) = 0x7f0c5e7f8000 < > write(1, "Hello there\n", 12Hello there ) = 12 < > rt_sigprocmask(sig_block, [CHLD], [], 8) = 0 < > rt_sigaction(sigchld, NULL, {SIG_DFL, [], 0}, 8) = 0 < > rt_sigprocmask(sig_setmask, [], NULL, 8) = 0 < > nanosleep({1, 0}, 0x7fffcc311f70) = 0 < > write(1, "Goodbye!\n", 9Goodbye! ) = 9 < > write(1, "Hello there\n", 12Hello there ) = 12 < > rt_sigprocmask(sig_block, [CHLD], [], 8) = 0 < > rt_sigaction(sigchld, NULL, {SIG_DFL, [], 0}, 8) = 0 < > rt_sigprocmask(sig_setmask, [], NULL, 8) = 0 < > nanosleep({1, 0}, 0x7fffcc311f70) = 0 < > write(1, "Goodbye!\n", 9Goodbye! ) = 9 < > write(1, "Hello there\n", 12Hello there ) = 12 < > rt_sigprocmask(sig_block, [CHLD], [], 8) = 0 < > rt_sigaction(sigchld, NULL, {SIG_DFL, [], 0}, 8) = 0 < > rt_sigprocmask(sig_setmask, [], NULL, 8) = 0 < > nanosleep({1, 0}, 0x7fffcc311f70) = 0 < > write(1, "Goodbye!\n", 9Goodbye! ) = 9 < > write(1, "Hello there\n", 12Hello there ) = 12 < > rt_sigprocmask(sig_block, [CHLD], [], 8) = 0 < > rt_sigaction(sigchld, NULL, {SIG_DFL, [], 0}, 8) = 0 < > rt_sigprocmask(sig_setmask, [], NULL, 8) = 0 < > nanosleep({1, 0}, 0x7fffcc311f70) = 0 < > write(1, "Goodbye!\n", 9Goodbye! ) = 9 < > write(1, "Hello there\n", 12Hello there

23 ) = 12 < > rt_sigprocmask(sig_block, [CHLD], [], 8) = 0 < > rt_sigaction(sigchld, NULL, {SIG_DFL, [], 0}, 8) = 0 < > rt_sigprocmask(sig_setmask, [], NULL, 8) = 0 < > nanosleep({1, 0}, 0x7fffcc311f70) = 0 < > write(1, "Goodbye!\n", 9Goodbye! ) = 9 < > write(1, "Hello there\n", 12Hello there ) = 12 < > rt_sigprocmask(sig_block, [CHLD], [], 8) = 0 < > rt_sigaction(sigchld, NULL, {SIG_DFL, [], 0}, 8) = 0 < > rt_sigprocmask(sig_setmask, [], NULL, 8) = 0 < > nanosleep({1, 0}, 0x7fffcc311f70) = 0 < > write(1, "Goodbye!\n", 9Goodbye! ) = 9 < > write(1, "Hello there\n", 12Hello there ) = 12 < > rt_sigprocmask(sig_block, [CHLD], [], 8) = 0 < > rt_sigaction(sigchld, NULL, {SIG_DFL, [], 0}, 8) = 0 < > rt_sigprocmask(sig_setmask, [], NULL, 8) = 0 < > nanosleep({1, 0}, 0x7fffcc311f70) = 0 < > write(1, "Goodbye!\n", 9Goodbye! ) = 9 < > write(1, "Hello there\n", 12Hello there ) = 12 < > rt_sigprocmask(sig_block, [CHLD], [], 8) = 0 < > rt_sigaction(sigchld, NULL, {SIG_DFL, [], 0}, 8) = 0 < > rt_sigprocmask(sig_setmask, [], NULL, 8) = 0 < > nanosleep({1, 0}, 0x7fffcc311f70) = 0 < > write(1, "Goodbye!\n", 9Goodbye! ) = 9 < > write(1, "Hello there\n", 12Hello there ) = 12 < > rt_sigprocmask(sig_block, [CHLD], [], 8) = 0 < > rt_sigaction(sigchld, NULL, {SIG_DFL, [], 0}, 8) = 0 < > rt_sigprocmask(sig_setmask, [], NULL, 8) = 0 < > nanosleep({1, 0}, 0x7fffcc311f70) = 0 < > write(1, "Goodbye!\n", 9Goodbye! ) = 9 < > write(1, "Hello there\n", 12Hello there ) = 12 < > rt_sigprocmask(sig_block, [CHLD], [], 8) = 0 < > rt_sigaction(sigchld, NULL, {SIG_DFL, [], 0}, 8) = 0 < > rt_sigprocmask(sig_setmask, [], NULL, 8) = 0 < > nanosleep({1, 0}, 0x7fffcc311f70) = 0 < > write(1, "Goodbye!\n", 9Goodbye! ) = 9 < > write(1, "Hello there\n", 12Hello there ) = 12 < > rt_sigprocmask(sig_block, [CHLD], [], 8) = 0 < > rt_sigaction(sigchld, NULL, {SIG_DFL, [], 0}, 8) = 0 < > rt_sigprocmask(sig_setmask, [], NULL, 8) = 0 < > nanosleep({1, 0}, 0x7fffcc311f70) = 0 < > write(1, "Goodbye!\n", 9Goodbye! ) = 9 < > write(1, "Hello there\n", 12Hello there ) = 12 < > rt_sigprocmask(sig_block, [CHLD], [], 8) = 0 < > rt_sigaction(sigchld, NULL, {SIG_DFL, [], 0}, 8) = 0 < > rt_sigprocmask(sig_setmask, [], NULL, 8) = 0 < > nanosleep({1, 0}, 0x7fffcc311f70) = 0 < > write(1, "Goodbye!\n", 9Goodbye! ) = 9 < > exit_group(9) =? +++ exited with asc95@test:~/workspace $

24 Expliquer L'appel système qui prend le plus de temps est «nanosleep». Car le «sleep» va mettre en pause le processus tandis que les autres appels systèmes sont exécutés à une vitesse non perçu par l Homme. Même question avec le programme : #include <stdio.h> #include <unistd.h> void main() { int i=0; do { printf("hello there!\n"); sleep(1); printf("goodbye\n"); } while(i>12); } asc95@test:~/workspace $ strace -T./t3 execve("./t3", ["./t3"], [/* 70 vars */]) = 0 < > brk(0) = 0x22dc000 < > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) < > mmap(null, 8192, PROT_READ PROT_WRITE, MAP_PRIVATE MAP_ANONYMOUS, -1, 0) = 0x7f91d047c000 < > access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) < > open("~/.c9/local/lib/tls/x86_64/libc.so.6", O_RDONLY O_CLOEXEC) = -1 ENOENT (No such file or directory) < >

25 open("~/.c9/local/lib/tls/libc.so.6", O_RDONLY O_CLOEXEC) = -1 ENOENT (No such file or directory) < > open("~/.c9/local/lib/x86_64/libc.so.6", O_RDONLY O_CLOEXEC) = -1 ENOENT (No such file or directory) < > open("~/.c9/local/lib/libc.so.6", O_RDONLY O_CLOEXEC) = -1 ENOENT (No such file or directory) < > open("/etc/ld.so.cache", O_RDONLY O_CLOEXEC) = 3 < > fstat(3, {st_mode=s_ifreg 0644, st_size=59193,...}) = 0 < > mmap(null, 59193, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f91d046d000 < > close(3) = 0 < > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) < > open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY O_CLOEXEC) = 3 < > read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\37\2\0\0\0\0\0"..., 832) = 832 < > fstat(3, {st_mode=s_ifreg 0755, st_size= ,...}) = 0 < > mmap(null, , PROT_READ PROT_EXEC, MAP_PRIVATE MAP_DENYWRITE, 3, 0) = 0x7f91cfe96000 < > mprotect(0x7f91d , , PROT_NONE) = 0 < > mmap(0x7f91d , 24576, PROT_READ PROT_WRITE, MAP_PRIVATE MAP_FIXED MAP_DENYWRITE, 3, 0x1bb000) = 0x7f91d < > mmap(0x7f91d , 17088, PROT_READ PROT_WRITE, MAP_PRIVATE MAP_FIXED MAP_ANONYMOUS, -1, 0) = 0x7f91d < > close(3) = 0 < > mmap(null, 4096, PROT_READ PROT_WRITE, MAP_PRIVATE MAP_ANONYMOUS, -1, 0) = 0x7f91d046c000 < > mmap(null, 8192, PROT_READ PROT_WRITE, MAP_PRIVATE MAP_ANONYMOUS, -1, 0) = 0x7f91d046a000 < > arch_prctl(arch_set_fs, 0x7f91d046a740) = 0 < > mprotect(0x7f91d , 16384, PROT_READ) = 0 < > mprotect(0x600000, 4096, PROT_READ) = 0 < > mprotect(0x7f91d047e000, 4096, PROT_READ) = 0 < > munmap(0x7f91d046d000, 59193) = 0 < > fstat(1, {st_mode=s_ifchr 0620, st_rdev=makedev(136, 1),...}) = 0 < > mmap(null, 4096, PROT_READ PROT_WRITE, MAP_PRIVATE MAP_ANONYMOUS, -1, 0) = 0x7f91d047b000 < > write(1, "Hello there\n", 12Hello there ) = 12 < > rt_sigprocmask(sig_block, [CHLD], [], 8) = 0 < > rt_sigaction(sigchld, NULL, {SIG_DFL, [], 0}, 8) = 0 < > rt_sigprocmask(sig_setmask, [], NULL, 8) = 0 < > nanosleep({1, 0}, 0x7fffd269a570) = 0 < > write(1, "Goodbye!\n", 9Goodbye! ) = 9 < > exit_group(9) =? +++ exited with asc95@test:~/workspace $

26 C est toujours nanosleep Même raisonnement que pour le programme précédent Dernier exercice : Nous voulons visualiser avec l'outil Linux totem le film playfilm.avi - Pour cela je lance la commande : > strace -o totem.txt totem playfilm.avi En examinant le fichier totem.txt, faites un diagnostic de ce qui s'est passé. On a plus de 3 millions de lignes! > Brk(0)=0x99ab000 > access()=-1!!!! > mmap2() =0xb76f000 > access()=-1!!!! > open est toujours à 3 > fatat64()=0 > mmap2()=0xb76f000 > close(3)=0 > access()=-1!!!! > open est toujours à 3 > read()=512 >

27 On a tenté d ouvrir un fichier vidéo et movie maker c est lancé. Sauf que le fichier.avi n existe pas. Quelles sont les lignes de ce fichier qui vous permettent de faire le diagnostic? Le début Strace Strace est un utilitaire permettant de tracer/suivre les appels systèmes. Les appels systèmes sont les interfaces fondamentales entre les applications et le noyau. Généralement, ils ne sont pas appelés directement, mais via des wrappers de la glibc. Par exemples : fstat, mmap, open, close,... En utilisant Strace, on peut intercepter ces appels systèmes pour un processus ou une commande donnée. Strace est donc un outil puissant de dépannage pour tous les administrateurs et utilisateurs Unix/Linux.