Comment by hayst4ck | Hacker News Reader

Comment by hayst4ck | Hacker News Reader

Parent Full thread

As a somewhat experienced admin, I can't imagine killing a process on a port without first understanding what process is using that port and why it is using that port. If a process is supervised, then I can't imagine killing a process when there might be process specific logic encoded into a script to try first.

  lsof -P | grep LISTEN | grep $PORT
  kill $RELEVANT_PID

The rust script itself uses kill -9, which probably isn't the ideal behavior. SIGTERM and then SIGKILL after a timeout is probably the appropriate behavior for a script, but even more appropriate would be to figure out if it's supervised and `service stop` it.

The real problem with this script is that it violates the unix philosophy (https://en.wikipedia.org/wiki/Unix_philosophy). "Do one thing and do it well" is the main problem.

This program finds processes to kill AND it kills them AND it kills their children and it does each of those things poorly.

For this program to be better than `lsof` and `kill`, it would need to implement command line options for which type of signal to send. By the time that is implemented, a program with the same interface as kill will be implemented, and it would be better for that to be it's own program that could be piped too. What's left would be a program that finds a process listening to a specific port, and there are already plenty of good programs for that.

Counter argument is that i dont care about any of those arguments for the use case where i shut my laptop lid and now cant boot my dev server during local development

Yeah, that is fair. For that problem, from an admin perspective, killport becomes a bandaid for not fixing the bug of poor behavior when the laptop lid closes. Instead of finding an automatic technical solution that does the right thing, every developer must toil by running operational commands to resolve their hung server.

If you have a "cargo cult" culture rather than an "understand the problem" culture what happens is that you hire a new dev and teach them that when the lid closes, you run killport to get it running again. The environment takes 10 seconds to set up and that's fine. By the time you are 100 employees you have 100 employees killporting their dev server and now taking 2 minutes to restart.

If you're lucky you get an altruistic hero dev who says "screw this, I don't want to deal with this any more" and they solve it. If you're unlucky, the behavior gets scaled out to 1000 employees your dev server takes 10 minutes to initialize and your developer tools team is under resourced and has higher priority stuff to deal with since "dev server hung" already has a solution. That's a little hyperbolic, but I've seen similar things.

Maybe what you really want is a cron job or supervisor that health checks your environment and restarts it when it's hung. Maybe there's a place to shim open/close lid behavior. Maybe spinning disks are being used instead of SSD's. Maybe the problem is local dev environment instead of remote. Most of those suggestions are automations or mitigations. The real solution might be as simple as a configuration change.

It seems like a very solvable problem.

> now cant boot my dev server during local development

Why?

> Why?

Because you can't have two processes using the same port, and the process that was using the port is now not responding. Perhaps you don't even want to go through the process of learning what PID it has, you just want the port back so you can relaunch the dev server on localhost.

your criticisms of this program do not seem well-founded because your assuming that it will be used improperly. In many cases this is a very simple problem with a simple solution

> the process that was using the port is now not responding.

Yes, but why?

Between strace, ps, atop, lsof, logging, and understanding the OS and TCP, it shouldn't be horrific to figure out what is happening. The very same skills to understand the problem are valuable to a lot of problems and investing in one simple problem is a further investment in future problems. "I don't have the telemetry to understand this" is, if nothing else, a deferred problem. Having devs that aren't prepared for oncall is also a problem.

"Why is my process hung?" is something I hope most devs can solve.

Not solving a frequently hanging process is short-termism. Not solving problems creates a learned helplessness about systemic problems. They build up and get addressed too late.

> Because you can't have two processes using the same port

https://lwn.net/Articles/542629/

Maybe this is relevant: https://hea-www.harvard.edu/~fine/Tech/addrinuse.html

> criticisms of this program

I am a little harsh because it increases complexity when no increased complexity is needed. That is my only strong criticism, a whole new program is invoked when we have plenty of very sufficient (composable) tools already.

The progression you’re outlining here sounds perfectly acceptable to me. I encounter many problems per day and they aren’t always worth understanding and solving, especially if there is a 10s bandaid for it. When the bandaid becomes expensive, that’s when I’ll put in the effort to fix it.

I bet this wasn't motivated by the sys admin use case; as you say, people like you don't need this because they will do it manually with shell commands after due diligence.

This is for development environment: you know that tool foo always runs on port 8888; you want a clean slate before rerunning your tests/dev server/ whatever.

(But sure, personally I would say people should learn enough shell programming to use shell commands for this, or even make their own utility as a shell script/function, rather than use a one-off tool).

To avoid any unwanted matches with grep (e.g. ports 1999 and 19999), use:

    $ lsof -i:$port | grep LISTEN
    $ kill $pid

grep isn't necessary at all here:

  lsof -s TCP:LISTEN -i :$port

You could also add the -t option for direct piping to kill.

For me it would be

netstat -nap | grep port (to see the proc and get its pid)

and then kill -9 pid to kill it

Who told you to kill a process on a port without first understanding what process is using that port?

Reply on news.ycombinator.com