Witr - un outil qui explique pourquoi un processus s’exécute sur un système Linux

 (github.com/pranshuparmar)
38 points par GN⁺ 2025-12-27 | 1 commentaires | Partager sur WhatsApp
  • Witr (why-is-this-running) est un outil qui montre clairement pourquoi un processus, un service ou un port donné est en cours d’exécution sur un système Linux
  • Contrairement à ps, top, lsof et autres, qui montrent simplement « ce qui s’exécute », il affiche sur un seul écran la relation de causalité derrière le “pourquoi c’est en cours d’exécution”
  • Grâce à une analyse basée sur le PID, il suit l’origine du processus, son chemin d’exécution, la raison pour laquelle il est maintenu en vie et son contexte d’appartenance
  • Il explique la cause de l’exécution en s’intégrant à diverses sources comme systemd, docker, pm2, cron, shell, tout en fonctionnant en lecture seule et de manière non destructive
  • C’est un outil qui réduit le temps nécessaire à la compréhension lors du débogage et de la gestion d’incidents, et permet de saisir d’un coup d’œil la structure d’exécution de systèmes complexes

Objectif et concept

  • La question centrale de Witr est : « Pourquoi cela est-il en cours d’exécution ? (why-is-this-running) »
    • Il remonte l’origine et la cause de tous les éléments en cours d’exécution, qu’il s’agisse de processus, services ou ports
    • Il montre explicitement les causes d’exécution indirectes à travers plusieurs couches (superviseur, conteneur, service, shell, etc.)
  • Alors que les outils existants ne fournissent que l’état et les métadonnées, Witr exprime clairement les relations de causalité
  • Au final, il affiche sous une forme facile à lire pour un humain « ce qui s’exécute, comment, pourquoi et dans quel contexte »

Principaux objectifs

  • Expliquer la raison d’être d’un processus et fournir des informations au-delà de son simple état d’exécution
  • Réduire le temps de débogage et de gestion des incidents
  • Utilisable immédiatement sans configuration, avec garantie de sécurité en lecture seule
  • Donner la priorité à la clarté plutôt qu’à l’exhaustivité
  • N’inclut pas de fonctions de supervision, d’analyse de performance ni d’auto-récupération

Principe de fonctionnement

  • Tous les éléments sont interprétés avec le processus (PID) comme point central
    • Ports, services, conteneurs et commandes sont tous reliés à un PID
    • À partir du PID, il construit une chaîne de causalité d’exécution (causal chain)
  • Quatre questions clés
    1. Qu’est-ce qui est en cours d’exécution ?
    2. Comment cela a-t-il été démarré ?
    3. Qu’est-ce qui le maintient en vie ?
    4. À quel contexte cela appartient-il ?

Éléments pris en charge

  • Prend en charge comme cibles d’entrée les noms de processus/service, les PID et les numéros de port
    • Si plusieurs processus correspondent à un nom saisi, il demande de choisir un PID
    • Les options --pid et --port permettent une analyse ciblée sur un processus ou un port précis

Structure de sortie

  • Target : la cible spécifiée par l’utilisateur
  • Process : exécutable, PID, utilisateur, commande, heure de démarrage, nombre de redémarrages
  • Why It Exists : la chaîne d’ascendance causale (ancestry chain) du processus
  • Source : le système principal responsable de l’exécution (par ex. systemd, docker, pm2, cron ou shell)
  • Context : répertoire de travail, dépôt Git, conteneur Docker, informations de binding, etc.
  • Warnings : avertissements non bloquants comme exécution avec les droits root, écoute sur une interface publique, exécution de longue durée, usage mémoire excessif, etc.

Options de ligne de commande

  • --pid, --port : analyser un PID ou un port spécifique
  • --short : résumé sur une ligne
  • --tree : afficher l’arbre complet des processus
  • --json : sortie au format JSON
  • --warnings : afficher uniquement les avertissements
  • --no-color : désactiver les couleurs
  • --env : afficher uniquement les variables d’environnement
  • --help : afficher l’aide

Installation et suppression

  • Distribué sous la forme d’un binaire Linux statique unique
  • Installation par script (recommandée)
  • Installation manuelle
    • Téléchargement direct des binaires pour amd64 et arm64, avec vérification du checksum
    • Après attribution des droits d’exécution, déplacement dans le PATH
  • Vérification et suppression
    • Vérification avec witr --version et man witr
    • Suppression possible via sudo rm -f /usr/local/bin/witr
  • Prise en charge de Nix Flake : exécution possible avec nix run github:pranshuparmar/witr -- --port 5000

Plateforme et permissions

  • Linux uniquement
  • Collecte des informations via l’accès à /proc
    • La consultation de certaines informations sur les processus nécessite des droits sudo

À lire aussi

1 commentaires

 
GN⁺ 2025-12-27
Commentaires Hacker News

  • Proposition : la boucle GIF du README redémarre trop vite, ce qui rend la sortie difficile à lire
    Ce serait mieux qu’elle reste en pause quelques secondes de plus

    • Honnêtement, je pense que des captures d’écran valent mieux qu’un GIF
      La dernière image suffit à transmettre toutes les informations utiles
    • Merci pour le retour ! Au début ça me semblait correct, mais vu du point de vue de l’utilisateur c’était effectivement assez gênant
      J’ai déjà remplacé cela par une image statique, et merci pour toutes les suggestions
    • Moi aussi je pense que le GIF n’est pas vraiment nécessaire
      Il montre que la commande est rapide, mais tout est déjà visible sur la dernière image, et c’est aussi moins efficace en termes de bande passante
    • En fait, la solution la plus simple est de supprimer complètement l’animation
      Il suffit de laisser la sortie figée à 100 %. Tout le monde sait déjà à quoi ressemble quelqu’un qui tape dans un terminal
    • Pour générer automatiquement ce type de GIF, des utilitaires comme charmbracelet/vhs sont très utiles

  • Cet outil ne cherche pas à remplacer les outils de monitoring / d’observabilité existants
    Il sert plutôt à comprendre rapidement, une fois connecté en SSH, « pourquoi est-ce que ça tourne ? »
    Je suis prêt à ajuster l’orientation du projet en fonction des retours

    • Je trouve que c’est une idée vraiment maligne
      Il a toujours été difficile de comprendre à quoi sert un processus quand il commence à consommer beaucoup de ressources
      Au début, je pensais que l’outil expliquait aussi la fonction du processus, mais ce n’est pas le cas
      Cela reste malgré tout un super outil. Plus tard, on pourrait même l’étendre en combinant pages de man + base de données de processus

  • Ça a l’air utile, mais la sortie actuelle montre surtout le ppid, donc on voit « qui l’a lancé », pas vraiment « pourquoi il a été lancé »
    C’est bien de prendre en charge plusieurs formats de sortie. Pour les environnements automatisés, ce serait encore mieux d’avoir par défaut un format JSON ou facile à greper

    • Merci pour le retour ! J’étudie justement une façon de distinguer plus clairement le « qui » du « pourquoi »
      La sortie par défaut a été conçue pour être lisible par un humain, mais l’automatisation est déjà prise en charge via un flag JSON
      Je vais aussi réfléchir à un format plus simple à grep

  • Outil intéressant, mais installer un binaire avec curl ne me rassure pas
    Plus tard, on risque de se demander « comment ça a été installé ? » ou « les correctifs de sécurité sont-ils à jour ? »
    Ce serait bien d’avoir un paquet deb ou snap

    • Je comprends que l’installation via curl ne convienne pas à tout le monde
      Comme c’est une première version, j’ai commencé simplement, mais si l’outil gagne en popularité je prévois une distribution officielle de paquets
    • On dirait qu’une nouvelle commande utilitaire va bientôt arriver — wdtci : « what does this curl install? »
    • À noter qu’on peut aussi obtenir beaucoup d’informations avec la commande systemctl status $pid

  • La phrase « witr repose sur la confiance » et l’explication disant que le projet a été développé avec l’aide de l’IA / des LLM donnent une impression de contradiction

    • La phrase « parfois supervisé par un humain qui savait ce qu’il faisait » ressemble à une blague, mais lue sérieusement elle peut inquiéter
      Si les résultats du LLM sont relus et que la revue de code est faite correctement, cela peut inspirer confiance
      Cela dit, j’apprécie la transparence sur l’usage des LLM
    • Oui, cette phrase était écrite sur le ton de l’humour, et le LLM n’a joué qu’un rôle d’assistance
      Les vraies décisions ont été prises par des humains
    • Pour ma part, si le code fonctionne bien, ça me suffit
      Si le développement a été guidé par le résultat, ça me va
    • Cela dit, il reste toujours facile pour un malware de falsifier les relations entre processus
    • Honnêtement, je pense qu’un LLM peut parfois mieux comprendre la situation qu’un humain

  • C’est un outil vraiment superbe et utile
    Mais dans un environnement de production, il est difficile de l’utiliser immédiatement pour les raisons évoquées plus haut
    Ce serait bien d’avoir des paquets Debian ou RPM

    • Merci ! Comme c’est une première version, j’ai commencé simplement, mais si l’outil prend de l’ampleur je préparerai des paquets officiels

  • Pour compiler directement depuis les sources, il suffit d’utiliser la commande suivante

    CGO_ENABLED=0 go build -ldflags "-X main.version=dev -X main.commit=$(git rev-parse --short HEAD) -X 'main.buildDate=$(date +%Y-%m-%d)'" -o witr ./cmd/witr

    Personnellement, si un install.sh est fourni, je m’attends à ce qu’il privilégie une installation depuis les sources locales
    C’est ce genre de petits outils simples qui me font rester dans le terminal

    • Merci ! Grâce à @sestep, la prise en charge de Nix a déjà été ajoutée, donc plus d’inquiétude côté binaire
    • Sinon, on peut simplement utiliser cette Nix PR

  • Je me demande ce que signifie « Git repository name and branch »
    Est-ce une fonctionnalité qui détecte si le processus en cours d’exécution a été lancé depuis l’intérieur d’un dépôt Git ?

    • Exactement, le code remonte depuis le répertoire de travail du processus pour chercher un répertoire .git
      Lien vers le code concerné

  • L’idée est excellente. J’avais autrefois créé un alias « whodis » pour trouver le PID qui ouvre un port, mais ça, c’est bien plus puissant

    • Merci ! L’objectif est d’en faire le couteau suisse des informations PID

  • Outil vraiment impressionnant. Merci de l’avoir partagé
    Est-ce que ça vous dérangerait si je créais un paquet AUR ?

    • Bien sûr ! Un dépôt AUR, c’est génial. Merci beaucoup
    • Je ne suis pas l’auteur, mais ce serait vraiment bien d’avoir une version AUR
      L’un des atouts d’Arch, c’est que ce genre d’outils intéressants arrive très vite sur l’AUR