Show HN: Witr – Explain why a process is running on your Linux system

This is very clever. I've often needed to figure out what some running process was actually for (e.g. because it just started consuming a lot of some limited resource) but it never occurred to me that one could have a tool to answer that question. Well done.

---

Edit: Ah, ok, I slightly misunderstood - skimmed the README too quickly. I thought it was also explaining what the process did :D Still a clever tool, but thought it went a step further.

Perhaps you should add that though - combine Man page output with a database of known processes that run on various Linux systems and a mechanism for contributing PRs to extend that database...? Unlesss it's just me that often wants to know "what the fsck does /tmp/hax0r/deeploysketchyd actually do?" :P

I left a different comment, but I think this is good. You're example is 3306 and has a useful breakdown. Not everyone has that port memorized by trauma, and not every mysql instance uses that port.

New tools are always welcome, and having a purpose to explain a purpose seems like a good pitch.

  > the gif that loops in the README should pause on the screen

Thanks everyone for the feedback on the GIF! I though it looked good but when I went back to see it from a user's POV, it was really miserable, haha. I've already switched it to a static image, appreaciate everyone's input and suggestions.

I would also argue it shouldn't be a gif. It's nice that it shows the command is fast I guess but it's one command that's still visible in the final frame. Not as bandwidth efficient and agreed I can't read it all in time

You can make that problem irrelevant with the much, much simpler solution of not animating it at all. Stay paused on the output 100% of the time!

The gif is adding no value. I already know what typing text into a terminal looks like.

https://github.com/charmbracelet/vhs is a really good utility for automatically making these gifs.

Also the pause button seems to take the GIF back to its first frame, then resume from where I paused... either that or I need a good sleep.

I understand that installing via `curl` isn’t for everyone, but since this is the first release, I intentionally kept it simple. Now that the tool is gaining some traction, I can definitely plan proper packages for future releases. Thanks for your inputs.

new utility command coming soon! wdtci - "what does this curl install?"

`systemctl status $pid` will get you a lot

Alternatively you can use Nix! :P https://github.com/pranshuparmar/witr/pull/5

Thanks! Glad you like it Thanks to @sestep, Nix support is already added, so no need to worry about binaries.

Thank you, glad you liked it. Since this is the first release, I intentionally kept it simple. Now that the tool is gaining some traction, I can definitely plan proper packages for future releases. Thanks for your inputs.

The last bit

> supervised by a human who occasionally knew what he was doing.

seems in jest but I could be wrong. If omitted or flagged as actual sarcasm I would feel a lot better about the project overall. As long as you’re auditing the LLM’s outputs and doing a decent code review I think it’s reasonable to trust this tool during incidents.

I’ll admit I did go straight to the end of the readme to look for this exact statement. I appreciate they chose to disclose.

I'd not trust any app that parses /proc to obtain process information (for reasons [0]), specially if the machine has been compromised (unless by "incident", the author means another thing):

https://github.com/pranshuparmar/witr/tree/main/internal/lin...

It should be the last option.

[0] https://news.ycombinator.com/item?id=46364057

Fair enough! That line was meant tongue‑in‑cheek, and to be transparent about LLM usage. Rest assured, they were assistants, not authorities.

No to me. It just has to demonstrate to work well, which is plenty possible with a developer focused on outcome rather than process (though hopefully they cared a bit about process/architecture too).

Regardless of code correctness, it's easy enough for malware to spoof process relationships.

I agree, the LLM probably has a much better idea of what's happening than any human

It appears to walk up from the process's working directory searching for a .git directory: https://github.com/pranshuparmar/witr/blob/1e47bdb8fde179b17...

Not sure if you're the one who created it but the AUR for this is present and needs update for the latest version - https://aur.archlinux.org/packages/witr-bin

Im not the author but I would love for an AUR made for this ;)

My favorite thing about arch is how insanely quickly AURs pop up for interesting tools.

Thanks! Really appreciate it. No qualms at all — an AUR entry would be awesome!

Thanks for the feedback! I’ll look into showing who and why in a more distinct way. The default output is human-first, hence some extra line breaks, but the JSON flag is already there for automation. We can also see if it can be made more easily greppable.

Haha, glad you like it! Maybe "responsibility chain" will catch on.

Thank you, please feel free to share any feedback/ideas.

Thanks! Glad you like it Trying to make this a swiss army knife for PID information.

Thank you, please feel free to share any feedback/ideas.

No, it does not.

`witr` is trying to be a bit different. Here are few use cases to consider: - When a process started. - Which ports a process is using. - Which user started it. - From which directory it started. - env flag to list all the variables attached to the process. - json flag to use it programmatically.

You’re better off wiping and reinstalling the OS than trying to clean the system.

>I hope

Thanks! Funny enough, that was my thought too when creating it.

Haha, go for it!

Thank you, yes coming soon - https://github.com/pranshuparmar/witr/pull/9

Thank you.

Thank you, please feel free to share any feedback/ideas.

Thank you.