The Problem
When diagnosing what's running on a system, administrators typically reach for ps, top, lsof, or ss. These tools expose process state and metadata, but correlating why a process is running requires manually cross-referencing outputs across multiple utilities—supervisors, containers, services, and shell sessions. This investigation becomes especially opaque when processes have indirect ancestry or span multiple system layers. witr was built to eliminate this manual correlation step.
What This Does
witr traces the causality chain of running processes, explaining where a process originated, how it was started, and what system layers are responsible for its current state. The codebase is organized around three core modules: internal/proc/ — Platform-specific process introspection (Linux, macOS, Windows, FreeBSD). Contains per-OS implementations for reading cmdline, container context, user info, and resource limits. Notably includes containerdetect.go and platform-specific net.go, fd.go files. internal/source/ — Detection logic for various startup vectors: systemd, launchd, cron, supervisor processes, SSH, and container runtimes. Each platform has its own file (e.g., internal/source/systemdlinux.go, internal/source/launchddarwin.go). internal/target/ — Resolution targets for files, ports, and names, with platform-differentiated implementations.
The tool outputs either a human-readable summary or an interactive TUI dashboard (built with bubbletea, visible in vendor/github.com/charmbracelet/bubbletea/). Entry points are cmd/witr/main.go and cmd/witr/unsupported.go, with a documentation generator at internal/tools/docgen/main.go.
Configuration is minimal—go.mod manages dependencies, and a Makefile handles builds. Travis CI is configured (.github/workflows/), and 11 test files exist under internal/.
How To Use It
Installation: witr is distributed as a static binary. The README provides install scripts:
Unix
curl -fsSL https://raw.githubusercontent.com/pranshuparmar/witr/main/install.sh | bash
Windows PowerShell
irm https://raw.githubusercontent.com/pranshuparmar/witr/main/install.ps1 | iex
Alternatively, package managers (Homebrew, Conda, Winget, AUR, npm, ports) are tracked on Repology.
Running: After installation, invoke via:
witr
The tool defaults to showing running processes with their causality chains. Flags and options are documented in docs/cli/witr.md and the man page at docs/cli/witr.1.
Real-World Use
Consider a scenario where a developer notices an unexpected process in ps output. Without witr, they'd need to run lsof for port usage, systemctl for service status, docker ps for container check, and manually trace ancestry. With witr, a single command produces a formatted output tracing the process origin—whether it was spawned by systemd, a Docker container, a supervisor, or a shell session—highlighting the indirect chain that launched it.
Code Health & Issues
Tests & CI: 11 test files exist; Travis CI is configured across .github/workflows/. Coverage appears focused on platform-specific proc and source modules (internal/proc/test.go, internal/source/detecttest.go). License: LICENSE file is present at root. Dependencies: go.mod lists direct dependencies; vendor/ contains third-party packages including charmbracelet/bubbletea for TUI and atotto/clipboard. No obvious version conflicts detected. Cross-platform coverage: Source detection and process introspection are implemented per-OS (internal/proc/darwin.go, internal/proc/*_linux.go, etc.), which is extensive but increases surface area for platform-specific bugs. Documentation: docs/ contains CLI docs and a man page; a Medium post documents the project's origin.
Low risk: The project has structural expectations (tests, CI, license, lockfile) met, and the Go module boundary is well-managed via go.sum.
The Bottom Line
witr is a focused, well-structured tool for diagnosing process causality across Unix-like and Windows systems. The codebase demonstrates disciplined platform-specific handling and has the expected CI/license hygiene for a Go project. It's best suited for operators, DevOps engineers, and developers who need to trace why a process is running without manually correlating ps, lsof, systemctl, and docker ps outputs. The TUI mode adds interactive value for exploratory debugging.