J’avance toujours sur la playlist ansible avec la 125ème vidéo dédiée au développement de votre propre module. C’est sympa ansible mais ça fait pas tout. C’est un outil parmi tant d’autres à découvrir et à connaître. Et si vous me suivez régulièrement, j’aime explorer des outils récents et d’autres un peu moins récents… mais tout aussi nécessaire… voir plus.

Strace fait partie de cette classe d’outil sur lequel vous pouvez vous investir durablement et en profondeur. Et cela sans que cette connaissance ne puisse être remise en cause par une nième technologie qui vient mettre au placard ce que vous avez appris.

C’est pour cela qu’apprendre les rudiments du système demeurent et resteront longtemps valables. D’autant plus que celui-ci n’évolue pas si vite et ne va pas disparaitre ou changer complètement du jour au lendemain. C’est donc un placement sûr et durable. Et il faut toujours garder cela en tête… Et comme les vieux langages reprennent de la valeur avec le temps, je suis persuadé que des bases solides en système reprendront de la valeur quand cette compétence se fera plus rare avec l’émergence des clouds et autres couches permettant parfois de réduire les connaissances du système.

J’ai donc décidé de commencer cette formation strace sous forme de playlist. Certains n’y apprendront rien je m’en doute mais ce que je veux c’est initier des réflexes dans l’approche du troubleshooting et du debug. Et à travers celà renforcer et consolider ses bases en système.

Les origines de Strace

J’aime revenir aux sources avant de commencer à apprendre à utiliser une technologie. Cela permet de se mettre dans le bain tranquillement.

Alors Strace commence initialement en 1991 du côté de SunOS avant de rejoindre Linux en 1992. Donc on peut considérer que ce projet a plus de 30 ans !!! c’est magnifique tout de même.

Le site officiel : https://strace.io/

Le dépôt github : https://github.com/strace/strace

Maintenant il est embarqué sur la plupart des distributions Linux. Il faut dire qu’il se base sur un syscall un peu dédié à savoir ptrace (le comble pour un outil qui trace les syscalls).

Mais alors comment résumer un syscall ? Un appel système c’est le moyen de communiquer avec le kernel (noyau), à partir du user mode. Ce dernier c’est ce que nus utilisons au quotidien, là où tourne : les applications, le terminal, votre navigateur….

Un syscall est une fonction avec un objectif bien défini pour utiliser le kernel. Sur linux on compte environ 300 syscalls. D’ailleurs on ne les utilise pas souvent en direct on passe souvent par la LibC. Et pour les trouver rien de plus simple, il suffit de se rendre dans le chapitre 2 du man pour y découvrir leur documentation à commencer par :

man 2 syscall

Eh oui pas besoin d’en faire des tonnes.

Et vous pouvez y retrouver le fameux ptrace :

man 2 ptrace

et notamment la manière de l’utiliser en C :

       #include <sys/ptrace.h>
       long ptrace(enum __ptrace_request request, pid_t pid,
                   void *addr, void *data);

Et là on voit que l’on va travailler principalement avec les PID et donc les processus. Donc strace trace les processus via leurs syscalls.

Tout le monde ne peut pas tracer

On en entend pas souvent parler mais tout le monde ne peut pas tracer. Généralement on passe un petit coup de sudo et on en parle plus mais c’est plus fin que cela tout de même.

Un paramètre du kernel Linux permet de fixer cela dans :

/proc/sys/kernel/yama/ptrace_scope

Avec les valeurs :

0 : même UID
1 : ascendance (sinon élévation de privilèges)
2 : admin seulement
3 : interdit

Donc on peut faire évoluer ce paramètre temporairement avec un :

sudo sysctl -w kernel.yama.ptrace_scope=3

Là on vient d’interdire temporairement l’utilisation de strace.

Ou encore de manière permanente :

sudo echo 0 > /proc/sys/kernel/yama/ptrace_scope

Car il faut le rappeler strace va nuire à la performance du processus sur lequel il va s’attacher. Oui c’est le terme à employer car vous allez le voir il ne lui lache pas les baskets.

Alors vous pouvez fair votre première trace d’un simple ls par exemple :

strace ls

Et l’output calme un peu au début, voir va en convaincre quelques uns de ne plus le réutiliser. Mais le bon réflexe c’est de se dire que ce n’est rien que des choses qu’il faut débrousailler petits morceaux après petits morceaux. Et chacun de ces morceaux apporte terriblement en connaissance du fonctionnement du système. En effet, pour chacun on peut creuser profondémment les choses.

Quelques options pour débuter tranquillement

Pour ne pas prendre peur, on va commencer par 3 options très simples :

• s : permet de définir la longueur de la ligne d’output (si on résume). Par défaut à 32, on peut déjà utiliser un 80 voi run 1024 pour vraiment ne rien manquer.
• p : très important car nous n’allons pas toujours avoir la chance de lancer un process via strace comme nous venons de le faire pour ls. Alors nous allons nous attacher à un processus qui tourne déjà grâce à l’option -p suivie du pid du process (attention aux forks on verra cela après).
• o : l’output de strace n’est pas si évident que cela à capturer en effet il faut rediriger la sortie stderr vers stdout 2>&1, c’est pas très classe alors avec -o vous pourrez spécifier un fichier de sortie.

Donc une ligne de commande complète pour commencer gentillement serait :

strace -p <pid_du_process> -s 1024 -o strace.log

Voilà pour débuter avec strace. Bien sûr on ne va pas s’arrêter là car on a pratiquement rien découvert mais il faut bien commencer.

N’hésitez pas à rejoindre la chaine pour ne pas manquer les prochaines vidéos.