Witr – ein Tool, das erklärt, warum Prozesse auf Linux-Systemen laufen

 (github.com/pranshuparmar)
38 Punkte von GN⁺ 2025-12-27 | 1 Kommentare | Auf WhatsApp teilen
  • Witr (why-is-this-running) ist ein Tool, das auf Linux-Systemen klar zeigt, warum ein bestimmter Prozess, Dienst oder Port aktiv ist
  • Im Gegensatz zu bestehenden Tools wie ps, top oder lsof, die nur zeigen, „was läuft“, stellt es die Kausalzusammenhänge hinter dem „warum es läuft“ auf einem Bildschirm dar
  • Durch PID-basierte Analyse verfolgt es Ursprung, Startpfad, Fortbestand und Kontext eines Prozesses
  • Es erklärt die Ausführungsursache in Verbindung mit verschiedenen Quellen wie systemd, docker, pm2, cron, shell und arbeitet read-only und nicht destruktiv
  • Ein Tool, das beim Debugging und bei der Störungsbehebung die Zeit bis zum Verständnis verkürzt und die Laufzeitstruktur komplexer Systeme auf einen Blick erfassbar macht

Zweck und Konzept

  • Die Kernfrage von Witr lautet: „Warum läuft das hier? (why-is-this-running)“
    • Es verfolgt Ursprung und Ursache aller laufenden Elemente wie Prozesse, Dienste und Ports
    • Es zeigt indirekte Ausführungsursachen über mehrere Ebenen hinweg (Supervisor, Container, Service, Shell usw.) explizit an
  • Während bestehende Tools nur Status und Metadaten liefern, stellt Witr Kausalbeziehungen klar dar
  • Dadurch wird in einer für Menschen gut lesbaren Form ausgegeben, was läuft, wie es gestartet wurde, warum es läuft und in welchem Kontext

Hauptziele

  • Den Grund für die Existenz eines Prozesses erklären und mehr Informationen liefern als nur die reine Laufzeit
  • Debugging- und Incident-Response-Zeit verkürzen
  • Sofort ohne Konfiguration nutzbar, read-only und sicher
  • Klarheit vor Vollständigkeit
  • Keine Monitoring-, Performance-Analyse- oder Auto-Recovery-Funktionen enthalten

Funktionsweise

  • Alle Ziele werden prozesszentriert über die PID interpretiert
    • Ports, Dienste, Container und Befehle werden alle mit einer PID verknüpft
    • Auf Basis der PID wird eine causal chain der Ausführung aufgebaut
  • Vier Kernfragen
    1. Was läuft?
    2. Wie wurde es gestartet?
    3. Was hält es am Laufen?
    4. Zu welchem Kontext gehört es?

Unterstützte Ziele

  • Unterstützt Prozess-/Dienstnamen, PID und Portnummern als Eingaben
    • Wenn bei einer Namenseingabe mehrere Prozesse passen, wird zur Auswahl einer PID aufgefordert
    • Mit den Optionen --pid und --port ist eine Analyse eines bestimmten Prozesses oder Ports möglich

Ausgabestruktur

  • Target: das vom Benutzer angegebene Ziel
  • Process: ausführbare Datei, PID, Benutzer, Befehl, Startzeit, Anzahl der Neustarts
  • Why It Exists: die Ancestry Chain des Prozesses
  • Source: das zentrale System, das die Ausführung verantwortet (z. B. systemd, docker, pm2, cron oder shell)
  • Context: Arbeitsverzeichnis, Git-Repository, Docker-Container, Bind-Informationen usw.
  • Warnings: nicht blockierende Warnungen wie Ausführung mit Root-Rechten, Lauschen auf öffentlichen Interfaces, lange Laufzeit oder übermäßiger Speicherverbrauch

Kommandozeilenoptionen

  • --pid, --port: Analyse einer bestimmten PID oder eines bestimmten Ports
  • --short: einzeilige Zusammenfassung
  • --tree: vollständigen Prozessbaum anzeigen
  • --json: Ausgabe im JSON-Format
  • --warnings: nur Warnungen anzeigen
  • --no-color: Farben deaktivieren
  • --env: nur Umgebungsvariablen anzeigen
  • --help: Hilfe anzeigen

Installation und Entfernung

  • Wird als einzelne statische Linux-Binärdatei verteilt
  • Installation per Skript (empfohlen)
  • Manuelle Installation
    • Binärdateien für amd64 und arm64 direkt herunterladen und Prüfsumme verifizieren
    • Ausführungsrechte setzen und in den PATH verschieben
  • Verifikation und Entfernung
    • Mit witr --version und man witr prüfen
    • Kann mit sudo rm -f /usr/local/bin/witr entfernt werden
  • Nix-Flake-Unterstützung: Ausführung möglich mit nix run github:pranshuparmar/witr -- --port 5000

Plattform und Berechtigungen

  • Nur für Linux
  • Informationen werden über Zugriff auf /proc gesammelt
    • Für einige Prozessinformationen sind sudo-Rechte erforderlich

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-12-27
Hacker-News-Kommentare

  • Es wurde angemerkt, dass die GIF-Schleife im README zu schnell neu startet, sodass sich die Ausgabe nur schwer vollständig lesen lässt.
    Ein paar Sekunden mehr Pause wären gut.

    • Ehrlich gesagt finde ich Screenshots besser als GIFs.
      Schon der letzte Frame vermittelt alle nötigen Informationen.
    • Danke für das Feedback! Anfangs wirkte es okay, aber aus Sicht der Nutzer war es ziemlich unpraktisch.
      Ich habe es bereits durch ein statisches Bild ersetzt, und danke euch für all die Vorschläge.
    • Ich finde auch, dass das GIF nicht wirklich nötig ist.
      Es zeigt zwar, dass der Befehl schnell ist, aber alles steht bereits im letzten Frame, und die Bandbreiteneffizienz ist auch schlechter.
    • Die einfachste Lösung ist eigentlich, die Animation ganz wegzulassen.
      Man kann die Ausgabe einfach bei 100 % stehen lassen. Wie man in ein Terminal tippt, wissen ohnehin alle.
    • Um solche GIFs automatisch zu erzeugen, sind Utilities wie charmbracelet/vhs sehr nützlich.

  • Das Tool soll keine bestehenden Monitoring-/Observability-Tools ersetzen.
    Es ist dafür gedacht, nach einem SSH-Login schnell zu verstehen: „Warum läuft das hier eigentlich?“
    Je nach Feedback bin ich bereit, die Ausrichtung anzupassen.

    • Ich halte das für eine wirklich clevere Idee.
      Es war schon immer schwierig herauszufinden, welchem Zweck ein Prozess dient, wenn er plötzlich viele Ressourcen verbraucht.
      Anfangs dachte ich, es würde sogar die Funktion des Prozesses erklären, aber das ist nicht der Fall.
      Trotzdem ein tolles Tool. Später könnte man es vielleicht erweiterbar machen, indem man Manpages + eine Prozessdatenbank kombiniert.

  • Wirkt nützlich, aber die aktuelle Ausgabe zeigt meist nur die ppid, sodass man zwar sieht, „wer“ es gestartet hat, aber schwerer erkennt, „warum“ es läuft.
    Die Unterstützung mehrerer Ausgabeformate ist gut. Mit Blick auf Automatisierung wäre es noch besser, JSON oder ein grep-freundliches Format als Standard zu haben.

    • Danke für das Feedback! Ich prüfe gerade, wie sich „wer“ und „warum“ klarer voneinander trennen lassen.
      Die Standardausgabe ist für Menschen lesbar gestaltet, aber per JSON-Flag wird Automatisierung bereits unterstützt.
      Ich werde auch über ein Format nachdenken, das sich leichter mit grep verarbeiten lässt.

  • Interessantes Tool, aber die Installation des Binärprogramms per curl ist mir unangenehm.
    Später können dann Fragen auftauchen wie: „Wie wurde das eigentlich installiert?“ oder „Sind die Sicherheitspatches aktuell?“
    deb-Pakete oder snap wären schön.

    • Ich verstehe, dass die curl-Installation nicht für alle passt.
      Es ist die erste Veröffentlichung, deshalb wollte ich einfach starten, aber wenn das Projekt Anklang findet, plane ich eine offizielle Paketverteilung.
    • Es kommt wohl bald ein neues Utility-Kommando — wdtci: „what does this curl install?“
    • Zur Info: Mit dem Befehl systemctl status $pid bekommt man ebenfalls viele Informationen.

  • Der Satz „witr basiert auf Vertrauen“ und die Erklärung, es sei mit Hilfe von AI/LLM entwickelt worden, wirken widersprüchlich.

    • Der Satz „Manchmal hat ein Mensch, der wusste, was er tut, die Aufsicht übernommen“ wirkt zwar wie ein Witz, liest sich aber, ernst genommen, eher beunruhigend.
      Wenn die Ergebnisse des LLM geprüft und der Code ordentlich reviewt wurden, wirkt es trotzdem vertrauenswürdig.
      Positiv sehe ich, dass die Nutzung von LLMs transparent offengelegt wurde.
    • Ja, der Satz war humorvoll gemeint, und das LLM hatte nur eine unterstützende Rolle.
      Die eigentlichen Entscheidungen wurden von Menschen getroffen.
    • Für mich reicht es, wenn der Code gut funktioniert.
      Wenn er ergebnisorientiert entwickelt wurde, finde ich das in Ordnung.
    • Allerdings ist es für Schadsoftware nach wie vor leicht, Prozessbeziehungen zu fälschen.
    • Ehrlich gesagt glaube ich, dass ein LLM den Kontext manchmal sogar besser verstehen kann als ein Mensch.

  • Wirklich ein großartiges und nützliches Tool.
    Aber in Produktionsumgebungen ist es aus den oben genannten Gründen schwer, es sofort einzusetzen.
    Debian- oder RPM-Pakete wären wünschenswert.

    • Danke! Es ist die erste Veröffentlichung, deshalb habe ich es zunächst einfach gehalten, aber wenn es populär wird, bereite ich offizielle Pakete vor.

  • Wer direkt aus dem Quellcode bauen möchte, kann folgenden Befehl verwenden:

    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

    Persönlich würde ich bei vorhandenem install.sh eher erwarten, dass lokaler Quellcode bevorzugt installiert wird.
    Solche einfachen Tools sind genau der Grund, warum ich dem Terminal treu bleibe.

    • Danke! Dank @sestep wurde bereits Nix-Unterstützung hinzugefügt, also gibt es keine Sorge mehr wegen des Binärprogramms.
    • Oder man verwendet einfach den Nix-PR.

  • Ich frage mich, was „Git repository name and branch“ genau bedeutet.
    Erkennt das Tool, ob ein laufender Prozess innerhalb eines Git-Repositories gestartet wurde?

    • Genau, es läuft vom Arbeitsverzeichnis des Prozesses nach oben und sucht nach dem Verzeichnis .git.
      Link zum relevanten Code

  • Coole Idee. Mein früheres „whodis“-Alias diente dazu, die PID zu finden, die einen Port geöffnet hat, aber das hier ist deutlich mächtiger.

    • Danke! Das Ziel ist ein Schweizer Taschenmesser für PID-Informationen.

  • Wirklich ein erstaunliches Tool. Danke fürs Teilen.
    Wäre es in Ordnung, wenn ich ein AUR-Paket dafür erstelle?

    • Natürlich! Ein Eintrag im AUR wäre großartig. Vielen Dank.
    • Ich bin zwar nicht der Autor, aber eine AUR-Version wäre wirklich klasse.
      Einer der Vorteile von Arch ist, dass solche interessanten Tools extrem schnell im AUR landen.