3 ms·

I always have a bunch of local projects running, particularly during the weekend where I'm rarely working on one thing at a time. A big pain of mine was constan

I always have a bunch of local projects running, particularly during the weekend where I'm rarely working on one thing at a time. A big pain of mine was constantly running into port: Redis from one project blocking another, orphaned dev servers from old worktrees, Docker containers I forgot about. The usual fix is lsof -iTCP | grep ..., then figuring out what the PID actually is, then killing it. But I always forget the command, and it doesn’t really include all the information that I like. So I built this lightweight CLI. Single binary, no dependencies. It shows everything listening on localhost with process names, Docker container info, clickable URLs etc. Sure there are workarounds, but none that satisfied my need for a short, easily rememberable command. Also nothing really has the same satisfaction as running sonar kill 3000 — it just feels nice. I’ve already been approached by a few agent orchestration tools that have been struggling with the same thing. It's really useful when you have multiple agents running, but it's not built for just that use case, I have also find it handy when killing off all containers after a failed cleanup and so on. Also know that MCPs are dead and CLIs are the new thing in agentic coding, this might be a useful tool for Claude, particularly when a compose process exits before all containers are stopped. Open for contributions, ideas and feedback.

pluc 7mo ago
Have a look at Evan Hahn's murder util: https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/murder https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d...
- raskrebs 7mo ago
  Will check it out
- 0cf8612b2e1e 7mo ago
  Sold on the name alone. It also has the API I never realized I needed puts 'usage:' puts 'murder 123 # kill by pid' puts 'murder ruby # kill by process name' puts 'murder :3000 # kill by port'
embedding-shape 7mo ago
> I’ve already been approached by a few agent orchestration tools that have been struggling with the same thing Wow, this says more about the agent orchestration tool ecosystem than what you might think, that they're unable to kill child processes they themselves spawn makes it seem like they have zero clue about what they're doing. Probably why my impression always end up with "Wow, what a vibe-coded mess" when I look through the source of all these harnesses, they don't seem engineered at all.
- raskrebs 7mo ago
  [dead]
- msdz 7mo ago
  > that they're unable to [manage and] kill child processes they themselves spawn makes it seem like they have zero clue about what they're doing. Yeah, at the bare minimum these projects could also use something like portless[1] which literally maps ports to human- (and language model-)readable, named .localhost URLs. Which _should_ heavily alleviate assignment of processes to projects and vice versa, since at that point, hard-to-remember port numbers completely leave the equation. You could even imagine prefixing them if you've got that much going on for the ultimate "overview", like project1-db.localhost, project1-dev.localhost, etc. [1] https://port1355.dev/ https://port1355.dev/
  - embedding-shape 7mo ago
    Well, or just use port 0 like we've done for decades, read what port got used, then use that. No more port collisions ever. I thought most people were already aware of that by now, but judging from that project even existing, seems I was wrong.
    - hackerthemonkey 7mo ago
      That’s a little different, right? Using port 0 would imply that clients have not hard coded what port they should connect to and also we don’t mind having duplicate processes occupying other ports which are no longer on active use

pluc 7mo ago

Have a look at Evan Hahn's murder util: https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d949d346a4a73ccee2a99351aed285b/home/bin/bin/murder https://codeberg.org/EvanHahn/dotfiles/src/commit/843b9ee13d...

raskrebs 7mo ago
Will check it out
0cf8612b2e1e 7mo ago
Sold on the name alone. It also has the API I never realized I needed puts 'usage:' puts 'murder 123 # kill by pid' puts 'murder ruby # kill by process name' puts 'murder :3000 # kill by port'

embedding-shape 7mo ago

> I’ve already been approached by a few agent orchestration tools that have been struggling with the same thing Wow, this says more about the agent orchestration tool ecosystem than what you might think, that they're unable to kill child processes they themselves spawn makes it seem like they have zero clue about what they're doing. Probably why my impression always end up with "Wow, what a vibe-coded mess" when I look through the source of all these harnesses, they don't seem engineered at all.

raskrebs 7mo ago
[dead]
msdz 7mo ago
> that they're unable to [manage and] kill child processes they themselves spawn makes it seem like they have zero clue about what they're doing. Yeah, at the bare minimum these projects could also use something like portless[1] which literally maps ports to human- (and language model-)readable, named .localhost URLs. Which _should_ heavily alleviate assignment of processes to projects and vice versa, since at that point, hard-to-remember port numbers completely leave the equation. You could even imagine prefixing them if you've got that much going on for the ultimate "overview", like project1-db.localhost, project1-dev.localhost, etc. [1] https://port1355.dev/ https://port1355.dev/
- embedding-shape 7mo ago
  Well, or just use port 0 like we've done for decades, read what port got used, then use that. No more port collisions ever. I thought most people were already aware of that by now, but judging from that project even existing, seems I was wrong.
  - hackerthemonkey 7mo ago
    That’s a little different, right? Using port 0 would imply that clients have not hard coded what port they should connect to and also we don’t mind having duplicate processes occupying other ports which are no longer on active use