WITR: Why Is This Running? A Tool That Traces Process Causality, Not Just State

Introduction: The Troubleshooting Gap

When running experiments on servers, engineers often encounter a port suddenly occupied, an unknown Python process lingering in the background, or a forgotten service that auto-starts after reboot. The typical investigation workflow involves a chain of commands: ss to check ports, lsof to find the PID, ps to inspect the parent process, then further digging into systemctl, Docker, tmux, or SSH sessions. These tools each reveal a piece of the current state, but they leave the causal question—why is this process here?—to manual correlation.

What WITR Does

WITR (Why Is This Running?) consolidates that fragmented investigation into a single query. Instead of piping multiple commands, you run: witr --port 8080 The output is not just a PID and command name; it presents an ancestry chain that explains the causal path, for example:

systemd ➡️ pm2 ➡️ node ➡️ :8080

Multiple Entry Points

WITR accepts several starting objects:

By PID: witr --pid 1234 By port: witr --port 5432 By file: witr --file /var/lib/dpkg/lock By process or service name: witr nginx,

witr python3

Key Design Principles

Everything Is a Process Question

The project's README states a core principle: witr treats everything as a process question. Ports, services, containers, and commands are disparate system objects, but WITR maps them first to a PID. Once the target process is identified, the analysis follows a uniform chain:

Target ➡️ Process ➡️ Parent Process ➡️ Supervisor / Service ➡️ Source

This unification turns a scattered set of state inspections into a single, coherent causality trace.

From State to Causality

Traditional tools ( ps, ss, lsof, systemctl, docker ps) are mature at reporting state. The operational burden lies in correlating their outputs. WITR's standard output includes a dedicated Why It Exists section that displays the process ancestry chain, supplemented by Source and Context fields showing the working directory, Git repository, container membership, and network bindings. The author emphasizes that this shift—from observing state to explaining causality—is the project's core value, mirroring the essence of network and system troubleshooting where the time-consuming step is linking cause to effect.

Machine-Readable Output for Automation

Beyond human-readable output, WITR supports JSON formatting and explicit exit codes: witr --port 8080 --json The documentation explicitly states these features enable use in scripts, CI pipelines, and monitoring systems. As AI agents increasingly participate in server and network operations, such machine-interpretable causality data becomes a building block for automated reasoning, reducing the tool-boundary crossings that both humans and automation must navigate.

Conclusion

WITR does not invent new kernel tracing mechanisms; ps, lsof, ss, systemctl, and docker ps remain the underlying workhorses. Its contribution is reorganizing their fragmented information around the question an operator actually asks: Why is this running? For engineers who regularly debug servers, containers, and networks, WITR is a practical addition to the toolbox. For those building observability, automation, or AI-driven operations, the underlying philosophy—moving from state to causality—may be more significant than the tool itself.

Project repository: https://github.com/pranshuparmar/witr