3 ms·

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 tha

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 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.

joshribakoff 4y ago
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
- hayst4ck 4y ago
  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?
  - JoeyBananas 4y ago
    > 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
    - hayst4ck 4y ago
      > 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/ https://lwn.net/Articles/542629/ Maybe this is relevant: https://hea-www.harvard.edu/~fine/Tech/addrinuse.html 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.
  - janderland 4y ago
    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.
lma21 4y ago
To avoid any unwanted matches with grep (e.g. ports 1999 and 19999), use: $ lsof -i:$port | grep LISTEN $ kill $pid
- addingnumbers 4y ago
  grep isn't necessary at all here: lsof -s TCP:LISTEN -i :$port
  - hdjjhhvvhga 4y ago
    You could also add the -t option for direct piping to kill.
spapas82 4y ago
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
martini333 4y ago
Who told you to kill a process on a port without first understanding what process is using that port?
Myrmornis 4y ago
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).

joshribakoff 4y ago

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

hayst4ck 4y ago
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?
- JoeyBananas 4y ago
  > 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
  - hayst4ck 4y ago
    > 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/ https://lwn.net/Articles/542629/ Maybe this is relevant: https://hea-www.harvard.edu/~fine/Tech/addrinuse.html 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.
- janderland 4y ago
  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.

lma21 4y ago

To avoid any unwanted matches with grep (e.g. ports 1999 and 19999), use: $ lsof -i:$port | grep LISTEN $ kill $pid

addingnumbers 4y ago
grep isn't necessary at all here: lsof -s TCP:LISTEN -i :$port
- hdjjhhvvhga 4y ago
  You could also add the -t option for direct piping to kill.

spapas82 4y ago

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

martini333 4y ago

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

Myrmornis 4y ago

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).