6 ms·

Advantages over the usual command line approach? (which you can easily turn into an alias) kill $(lsof -t -i:8080)

retSava 4y ago
I can see writing such a tool when learning eg network programming in a new language, here rust.
nailer 4y ago
As someone who is good at unix but watches other people struggle with it: the advantage is that people don’t understand signals, subshells, what ls stands for, what of stands for, don’t know the manual, don’t know what man stands for, don’t know the manual has sections, and aren’t interested in finding out.
- BirAdam 4y ago
  I was going to say use kill and lsof, and also something similar to what you said here. I would add that even many seasoned developers don’t know UNIX-like systems well enough to do anything with native tooling and therefore replicate native functionality poorly and slowly. For many people, it’s faster to write an entirely new tool than it is to go learn the platform for which they’re writing and therefore they do it.
  - Joker_vD 4y ago
    That definitely says something about the discoverability of the platform's functionality. The similar thing also regularly happens in medium-to-large codebases so that's how you end with four slighlty different implementations of e.g. "extract value by path from a JSON object, with some traversal options": it's easier to just write the damn loop by yourself than to find a) if it's already been written, and if yes, b) how the hell do you use it.
    - FpUser 4y ago
      >"That definitely says something about the discoverability of the platform's functionality." I think it says more about people being lazy and not willing to use that mighty tool called search (add ChatGPT now). Even here on HN I often see people asking what is X when that X is one web search away.
      - Karunamon 4y ago
        That one is at least defensible, a Q and A in a public forum can be a seed that generates further discussion and provides knowledge to others.
      - Joker_vD 4y ago
        Yeah, agreed, we should change human psychology to fit our current technological stack better, that sounds way easier than doing the opposite. On a serious note, I do hope that built-in help systems with ChatGPT glued on (and additionally trained on its contents) will become a de-facto standard in the near future: it should be possible to just ask your computing environment "how do I do X with you?" and get an answer or at least some guidance pointers.
        FpUser 4y ago
        The scope of modern OS, its utilities and commands is so large that good and comprehensive doc would be huge. And that is just the description of command with options. How do I do X is even more complex and may require things that go way beyond the simple doc and will require books. This is just not scalable and impractical. Having piles of common knowledge like Stack Overflow / forums / etc augmented with search and now ChatGPT is way more practical. I've personally written what is very comprehensive doc for one of my software products. It described every nook and cranny. Still I ended up supporting a forum with most common questions percolated to a dedicated How Do I Do XYZ section and it just keeps growing. In the beginning I was answering question there. Now I just see people supporting themselves.
    - mschuster91 4y ago
      > That definitely says something about the discoverability of the platform's functionality. Meh. Back in ye olde days, when developers were either self-taught from the roots or came from universities, they just knew that stuff from experience. Nowadays, a lot of "developers" come from three months "coder bootcamps". They may even be reasonably proficient in whatever flavor of JS toolkit the camps teach at the moment, but they will have zero knowledge about what makes their computer tick.
  - FpUser 4y ago
    I am not good at knowing Linux at all beyond some general concepts. If I did my brain would have no room left. However when dealing with it I always assume that it has everything and do google search. I do not remember a single case when I would want to write some utility. The ones available along with bash always cover all of my needs leaving me more time to design and implement the actual software I am being paid for. My whole CI/CD or whatever complete management is called is few bash scripts.
- magicalhippo 4y ago
  So as someone who's not very good at UNIX, knows that it has signals, subshell, what ls is, don't know of, know there's a manual and has invoked man many times and is interested in finding out... How would I use man to find that lsof exists so that I could come up with the incantation mentioned in OP? I tried "man -k 'open'" but none of the answers returns lsof on my system. I checked that "man lsof" works as expected.
  - pxc 4y ago
    man -k open should surface lsof on your system. On mine it only has the description 'open files', though, which might not be obviously relevant to many people. I'm not sure what macOS or FreeBSD `man` have, but GNU `man` has `-K` as well as `-k`. The uppercase version searches the manpages globally, instead of just their short descriptions. So something like man -K -a 8 "list open" port will turn up `lsof` on GNU, even if `apropos` doesn't. If you have a tldr client installed, that can also be useful for searching through common examples including for programs you may not have installed. For example with tealdeer, the following (Fish) surfaces both lsof and netstat as options: for page in (tldr -l) tldr $page | rg -A2 -i '\b(find|list)\b.*\bport' end and for page in (tldr -l) tldr $page | rg -A2 -i '\bkill\b.*\bport' end shows that fuser and fkill can both do the same thing as killport. Grep sucks as a search interface for tldr, though, so you probably want a better tldr client than I have, which will do global search, or an FZF script that will let you filter through tldr results. Discovering new (to you) tools which are not yet installed is a good reason to use the web to look up Unix stuff, especially after you've checked the manpages and your package manager.
    - magicalhippo 4y ago
      Thanks for the detailed response. Seems -K is not available on the UNIX I have (TrueNAS, FreeBSD-based). That should indeed have helped. > Discovering new (to you) tools which are not yet installed is a good reason to use the web to look up Unix stuff Of course a web search can help, however I often find that the times when I need to do such searches is quite correlated with times when I don't have internet access. Less frequent now with my "smart" phone, but still happens.
- pxc 4y ago
  > don’t know what man stands for, don’t know the manual has sections, and aren’t interested in finding out People that unwilling to learn— uninterested in even discovering that there is a manual and how to open it— don't belong in software. The rest of the things you mention... whatever. Many people haven't heard a good pitch. They haven't had the relevant experience to see how investing in learning those things can pay off for them. But disinterest in finding out that there's a manual? That's wilful incompetence of a kind I've never seen and hope I never will.
xk_id 4y ago
I’m not sure either. It looks more like a contrived implementation for the sake of using Rust. P.s: functions are almost always preferable over aliases
- cassepipe 4y ago
  (Heavy alias user. Why are funcions to be prefered over aliases ?)
  - xk_id 4y ago
    Well my comment was actually a reference to the manual [0]. But I agree with it, because aliases are just a string substitution for interactive shells, so they are limited. I found that I often end up wanting to add additional logic (such as arguments or local variables) and to have it available for use in scripts later. [0] https://www.gnu.org/software/bash/manual/html_node/Aliases.html https://www.gnu.org/software/bash/manual/html_node/Aliases.h...
ghayes 4y ago
I’ll only argue that lsof is a command for which I need to lookup the argument structure every time. Relevant xkcd: https://xkcd.com/1168/ https://xkcd.com/1168/
- jve 4y ago
  At least it didn't say "no man" :) Anyways, I always wanted to map pid/user/port, so TIL: lsof. I may not come up with that single liner when I need but `lsof -i` (i for internet) is ok for me to resolve some issue. Err, `sudo lsof -i`
pankajdoharey 4y ago
I was thinking the same thing. Quite a bit of effort, 3 Branches 26 commits and Rust (The effort gone in taming the beast). The hacker mindset is usually to avoid over engineering, saving efforts by avoiding a solved problem.
- nodemaker 4y ago
  Typical rust programmer
  - pankajdoharey 4y ago
    Typical bash programmer : https://github.com/metacritical/killport https://github.com/metacritical/killport
rvz 4y ago
That doesn't work on Windows and it isn't portable. At least with Rust it can be abstracted and made to be portable, to work on other platforms like Windows. Why learn 3 different commands with slightly non-standard arguments to find and kill a process on different OSes, when you can use one unified command and the arguments work the same as expected?
- Joker_vD 4y ago
  "Different OSes"? There is only Linux in different tastes and maybe some BSD in some obscure places but no other OSes exist (that are worth to get oneself acquainted with), I am pretty sure of it.
  - rvz 4y ago
    > There is only Linux in different tastes and maybe some BSD in some obscure places. This is why most people (and developers) still use the Windows Desktop and not the thousands of Linux Desktop(s) out there. > But no other OSes exist (that are worth to get oneself acquainted with) macOS exists and it works with that. Rust supports Windows as well so it is certainly possible to port it to Windows. Literally someone asked for Windows. [0] > I am pretty sure of it. Henceforth, I don't think you are even sure. [0] https://news.ycombinator.com/item?id=35698882 https://news.ycombinator.com/item?id=35698882
    - jraph 4y ago
      > macOS exists and it works with that your parent poster is obviously trolling, but macOS is some kind of BSD, so they actually took this case in account.
      - rvz 4y ago
        My point still stands about Windows, regardless.
        forgotmypw17 4y ago
jraph 4y ago
I see one advantage: it allowed me to run into your comment :-)
madethemcry 4y ago
Well, the simple explanation is probably that the author isn't aware of `lsof` and might even learn something from your comment. lsof isn't something you automatically pickup if it's not your daily business (like so many other things). I for myself often forget about it but I have some usual ports to kill. So these days I simply search my shell history by port to find lsof again.
- nsteel 4y ago
  True, but there's no shortage of Stack Overflow answers: https://www.google.com/search?hl=en&q=kill%20process%20on%20port https://www.google.com/search?hl=en&q=kill%20process%20on%20...
- sumedh 4y ago
  > lsof isn't something you automatically pickup if it's not your daily business Its a good thing now we have chatGpt to help us :)
- djha-skin 4y ago
  I've known about LSOF and about kill but I've never put them together like this. I find his tool compelling simply because now I don't have to remember all this stuff. What we really need is a tool like this for Windows. Find the process that keeps this file open and kill it. It's so annoying when I can't delete a file because some process has it open but I can't tell which one.
  - darrenf 4y ago
    `handle` from sysinternals gets you some of the way there. Maybe all of the way there? (I haven't used Windows in over a decade) https://learn.microsoft.com/en-us/sysinternals/downloads/handle https://learn.microsoft.com/en-us/sysinternals/downloads/han...
  - panki27 4y ago
    Powertoys for Windows has added a "What is blocking this file?" feature recently. https://learn.microsoft.com/en-us/windows/powertoys/file-locksmith https://learn.microsoft.com/en-us/windows/powertoys/file-loc...
beezlewax 4y ago
Does this work on windows? I've been using a npm package for this "port-kill". The problem is less that people don't understand shell commands but more there is too much stuff to remember. An alias works well for this stuff but then you have to set it up everywhere you work. Sometimes downloading a package is just easier. npx kill-port 8080
- dexterdog 4y ago
  That's why you have a set of dotfiles that you use as your base wherever you go. Store it at a url you know and as long as you have wget or curl it's 1 line away. Then you don't have to remember whatever the author decided to name the package.
- funcDropShadow 4y ago
  > The problem is less that people don't understand shell commands but more there is too much stuff to remember. But is it really better in the long run to add more and more additional tools? Is it less work to understand and remember more uses of fewer commands or is it less work to understand and remember more specialized commands? The latter is clearly more administrative work, because you have to install all those tools on your machines. On the other hand, finding more uses of a few select tools creates those associations in your brain that you need to cover new usages for them yourself. To me that's a clear win for the side of fewer well-understood tools.
ziml77 4y ago
Huh I had no idea lsof could be used like that. I've always used netstat to find what process was using a given port.
nsxwolf 4y ago
The UX of "killport 8080" vs Googling the stack overflow on what you just typed every time is way better.
- OJFord 4y ago
  You don't have to do it exactly like that or probably 'google the stack overflow' once you've used kill & lsof (whether for this purpose of something else). My thought as GP's as soon as I read the title was 'lsof & kill?' - I doubt they looked up the pretty simple command they gave. And as they said, 'which you can easily turn into an alias [well, a function]', which you could call 'killport' if you want for exactly the same functionality.
  - nsxwolf 4y ago
    You could do that too. UNIX gives you a lot of options.
    - OJFord 4y ago
      Do what too?
- recov 4y ago
  function killport() { kill $(lsof -t -i:$1) }
- deleted 4y ago
  [deleted]
- bashinator 4y ago
  As a sysadmin, `lsof` is part of my standard toolkit; I wouldn't be able to do my job if I had to look stuff like that up on Stackoverflow every time.
  - deleted 4y ago
    [deleted]
  - 4y ago
darrenf 4y ago
I really don't think I trust this approach, despite it being vouched for by so many responders to this thread. When I run this: sudo lsof -t -i :22 I expected to get sshd and nothing else, but it actually includes outgoing ssh connections too - which I don't want to kill. Likewise :443 gives clients like the pids of firefox and signal. I'm gonna stick with `fuser`.
leejoramo 4y ago
When killing by port number, you usually want to restrict to the LISTENING server port. Otherwise you will likely kill things connecting to the port. For example, in a local development environment the above command would kill both the web server and the ALL web browsers with an open page to that server That is the full browser instance not just the specific tab connection to the server This is the command I would use. > kill -9 (lsof -nP -t -iTCP:8080 -sTCP:LISTEN)

I can see writing such a tool when learning eg network programming in a new language, here rust.

As someone who is good at unix but watches other people struggle with it: the advantage is that people don’t understand signals, subshells, what ls stands for, what of stands for, don’t know the manual, don’t know what man stands for, don’t know the manual has sections, and aren’t interested in finding out.

BirAdam 4y ago
I was going to say use kill and lsof, and also something similar to what you said here. I would add that even many seasoned developers don’t know UNIX-like systems well enough to do anything with native tooling and therefore replicate native functionality poorly and slowly. For many people, it’s faster to write an entirely new tool than it is to go learn the platform for which they’re writing and therefore they do it.
- Joker_vD 4y ago
  That definitely says something about the discoverability of the platform's functionality. The similar thing also regularly happens in medium-to-large codebases so that's how you end with four slighlty different implementations of e.g. "extract value by path from a JSON object, with some traversal options": it's easier to just write the damn loop by yourself than to find a) if it's already been written, and if yes, b) how the hell do you use it.
  - FpUser 4y ago
    >"That definitely says something about the discoverability of the platform's functionality." I think it says more about people being lazy and not willing to use that mighty tool called search (add ChatGPT now). Even here on HN I often see people asking what is X when that X is one web search away.
    - Karunamon 4y ago
      That one is at least defensible, a Q and A in a public forum can be a seed that generates further discussion and provides knowledge to others.
    - Joker_vD 4y ago
      Yeah, agreed, we should change human psychology to fit our current technological stack better, that sounds way easier than doing the opposite. On a serious note, I do hope that built-in help systems with ChatGPT glued on (and additionally trained on its contents) will become a de-facto standard in the near future: it should be possible to just ask your computing environment "how do I do X with you?" and get an answer or at least some guidance pointers.
      - FpUser 4y ago
        The scope of modern OS, its utilities and commands is so large that good and comprehensive doc would be huge. And that is just the description of command with options. How do I do X is even more complex and may require things that go way beyond the simple doc and will require books. This is just not scalable and impractical. Having piles of common knowledge like Stack Overflow / forums / etc augmented with search and now ChatGPT is way more practical. I've personally written what is very comprehensive doc for one of my software products. It described every nook and cranny. Still I ended up supporting a forum with most common questions percolated to a dedicated How Do I Do XYZ section and it just keeps growing. In the beginning I was answering question there. Now I just see people supporting themselves.
  - mschuster91 4y ago
    > That definitely says something about the discoverability of the platform's functionality. Meh. Back in ye olde days, when developers were either self-taught from the roots or came from universities, they just knew that stuff from experience. Nowadays, a lot of "developers" come from three months "coder bootcamps". They may even be reasonably proficient in whatever flavor of JS toolkit the camps teach at the moment, but they will have zero knowledge about what makes their computer tick.
- FpUser 4y ago
  I am not good at knowing Linux at all beyond some general concepts. If I did my brain would have no room left. However when dealing with it I always assume that it has everything and do google search. I do not remember a single case when I would want to write some utility. The ones available along with bash always cover all of my needs leaving me more time to design and implement the actual software I am being paid for. My whole CI/CD or whatever complete management is called is few bash scripts.
magicalhippo 4y ago
So as someone who's not very good at UNIX, knows that it has signals, subshell, what ls is, don't know of, know there's a manual and has invoked man many times and is interested in finding out... How would I use man to find that lsof exists so that I could come up with the incantation mentioned in OP? I tried "man -k 'open'" but none of the answers returns lsof on my system. I checked that "man lsof" works as expected.
- pxc 4y ago
  man -k open should surface lsof on your system. On mine it only has the description 'open files', though, which might not be obviously relevant to many people. I'm not sure what macOS or FreeBSD `man` have, but GNU `man` has `-K` as well as `-k`. The uppercase version searches the manpages globally, instead of just their short descriptions. So something like man -K -a 8 "list open" port will turn up `lsof` on GNU, even if `apropos` doesn't. If you have a tldr client installed, that can also be useful for searching through common examples including for programs you may not have installed. For example with tealdeer, the following (Fish) surfaces both lsof and netstat as options: for page in (tldr -l) tldr $page | rg -A2 -i '\b(find|list)\b.*\bport' end and for page in (tldr -l) tldr $page | rg -A2 -i '\bkill\b.*\bport' end shows that fuser and fkill can both do the same thing as killport. Grep sucks as a search interface for tldr, though, so you probably want a better tldr client than I have, which will do global search, or an FZF script that will let you filter through tldr results. Discovering new (to you) tools which are not yet installed is a good reason to use the web to look up Unix stuff, especially after you've checked the manpages and your package manager.
  - magicalhippo 4y ago
    Thanks for the detailed response. Seems -K is not available on the UNIX I have (TrueNAS, FreeBSD-based). That should indeed have helped. > Discovering new (to you) tools which are not yet installed is a good reason to use the web to look up Unix stuff Of course a web search can help, however I often find that the times when I need to do such searches is quite correlated with times when I don't have internet access. Less frequent now with my "smart" phone, but still happens.
pxc 4y ago
> don’t know what man stands for, don’t know the manual has sections, and aren’t interested in finding out People that unwilling to learn— uninterested in even discovering that there is a manual and how to open it— don't belong in software. The rest of the things you mention... whatever. Many people haven't heard a good pitch. They haven't had the relevant experience to see how investing in learning those things can pay off for them. But disinterest in finding out that there's a manual? That's wilful incompetence of a kind I've never seen and hope I never will.

xk_id 4y ago

I’m not sure either. It looks more like a contrived implementation for the sake of using Rust. P.s: functions are almost always preferable over aliases

cassepipe 4y ago
(Heavy alias user. Why are funcions to be prefered over aliases ?)
- xk_id 4y ago
  Well my comment was actually a reference to the manual [0]. But I agree with it, because aliases are just a string substitution for interactive shells, so they are limited. I found that I often end up wanting to add additional logic (such as arguments or local variables) and to have it available for use in scripts later. [0] https://www.gnu.org/software/bash/manual/html_node/Aliases.html https://www.gnu.org/software/bash/manual/html_node/Aliases.h...

ghayes 4y ago

I’ll only argue that lsof is a command for which I need to lookup the argument structure every time. Relevant xkcd: https://xkcd.com/1168/ https://xkcd.com/1168/

jve 4y ago
At least it didn't say "no man" :) Anyways, I always wanted to map pid/user/port, so TIL: lsof. I may not come up with that single liner when I need but `lsof -i` (i for internet) is ok for me to resolve some issue. Err, `sudo lsof -i`

pankajdoharey 4y ago

I was thinking the same thing. Quite a bit of effort, 3 Branches 26 commits and Rust (The effort gone in taming the beast). The hacker mindset is usually to avoid over engineering, saving efforts by avoiding a solved problem.

nodemaker 4y ago
Typical rust programmer
- pankajdoharey 4y ago
  Typical bash programmer : https://github.com/metacritical/killport https://github.com/metacritical/killport

rvz 4y ago

That doesn't work on Windows and it isn't portable. At least with Rust it can be abstracted and made to be portable, to work on other platforms like Windows. Why learn 3 different commands with slightly non-standard arguments to find and kill a process on different OSes, when you can use one unified command and the arguments work the same as expected?

Joker_vD 4y ago
"Different OSes"? There is only Linux in different tastes and maybe some BSD in some obscure places but no other OSes exist (that are worth to get oneself acquainted with), I am pretty sure of it.
- rvz 4y ago
  > There is only Linux in different tastes and maybe some BSD in some obscure places. This is why most people (and developers) still use the Windows Desktop and not the thousands of Linux Desktop(s) out there. > But no other OSes exist (that are worth to get oneself acquainted with) macOS exists and it works with that. Rust supports Windows as well so it is certainly possible to port it to Windows. Literally someone asked for Windows. [0] > I am pretty sure of it. Henceforth, I don't think you are even sure. [0] https://news.ycombinator.com/item?id=35698882 https://news.ycombinator.com/item?id=35698882
  - jraph 4y ago
    > macOS exists and it works with that your parent poster is obviously trolling, but macOS is some kind of BSD, so they actually took this case in account.
    - rvz 4y ago
      My point still stands about Windows, regardless.
      - forgotmypw17 4y ago

jraph 4y ago

I see one advantage: it allowed me to run into your comment :-)

madethemcry 4y ago

Well, the simple explanation is probably that the author isn't aware of `lsof` and might even learn something from your comment. lsof isn't something you automatically pickup if it's not your daily business (like so many other things). I for myself often forget about it but I have some usual ports to kill. So these days I simply search my shell history by port to find lsof again.

nsteel 4y ago
True, but there's no shortage of Stack Overflow answers: https://www.google.com/search?hl=en&q=kill%20process%20on%20port https://www.google.com/search?hl=en&q=kill%20process%20on%20...
sumedh 4y ago
> lsof isn't something you automatically pickup if it's not your daily business Its a good thing now we have chatGpt to help us :)
djha-skin 4y ago
I've known about LSOF and about kill but I've never put them together like this. I find his tool compelling simply because now I don't have to remember all this stuff. What we really need is a tool like this for Windows. Find the process that keeps this file open and kill it. It's so annoying when I can't delete a file because some process has it open but I can't tell which one.
- darrenf 4y ago
  `handle` from sysinternals gets you some of the way there. Maybe all of the way there? (I haven't used Windows in over a decade) https://learn.microsoft.com/en-us/sysinternals/downloads/handle https://learn.microsoft.com/en-us/sysinternals/downloads/han...
- panki27 4y ago
  Powertoys for Windows has added a "What is blocking this file?" feature recently. https://learn.microsoft.com/en-us/windows/powertoys/file-locksmith https://learn.microsoft.com/en-us/windows/powertoys/file-loc...

beezlewax 4y ago

Does this work on windows? I've been using a npm package for this "port-kill". The problem is less that people don't understand shell commands but more there is too much stuff to remember. An alias works well for this stuff but then you have to set it up everywhere you work. Sometimes downloading a package is just easier. npx kill-port 8080

dexterdog 4y ago
That's why you have a set of dotfiles that you use as your base wherever you go. Store it at a url you know and as long as you have wget or curl it's 1 line away. Then you don't have to remember whatever the author decided to name the package.
funcDropShadow 4y ago
> The problem is less that people don't understand shell commands but more there is too much stuff to remember. But is it really better in the long run to add more and more additional tools? Is it less work to understand and remember more uses of fewer commands or is it less work to understand and remember more specialized commands? The latter is clearly more administrative work, because you have to install all those tools on your machines. On the other hand, finding more uses of a few select tools creates those associations in your brain that you need to cover new usages for them yourself. To me that's a clear win for the side of fewer well-understood tools.

ziml77 4y ago

Huh I had no idea lsof could be used like that. I've always used netstat to find what process was using a given port.

nsxwolf 4y ago

The UX of "killport 8080" vs Googling the stack overflow on what you just typed every time is way better.

OJFord 4y ago
You don't have to do it exactly like that or probably 'google the stack overflow' once you've used kill & lsof (whether for this purpose of something else). My thought as GP's as soon as I read the title was 'lsof & kill?' - I doubt they looked up the pretty simple command they gave. And as they said, 'which you can easily turn into an alias [well, a function]', which you could call 'killport' if you want for exactly the same functionality.
- nsxwolf 4y ago
  You could do that too. UNIX gives you a lot of options.
  - OJFord 4y ago
    Do what too?
recov 4y ago
function killport() { kill $(lsof -t -i:$1) }
deleted 4y ago
[deleted]
bashinator 4y ago
As a sysadmin, `lsof` is part of my standard toolkit; I wouldn't be able to do my job if I had to look stuff like that up on Stackoverflow every time.
- deleted 4y ago
  [deleted]
- 4y ago

darrenf 4y ago

I really don't think I trust this approach, despite it being vouched for by so many responders to this thread. When I run this: sudo lsof -t -i :22 I expected to get sshd and nothing else, but it actually includes outgoing ssh connections too - which I don't want to kill. Likewise :443 gives clients like the pids of firefox and signal. I'm gonna stick with `fuser`.

leejoramo 4y ago

When killing by port number, you usually want to restrict to the LISTENING server port. Otherwise you will likely kill things connecting to the port. For example, in a local development environment the above command would kill both the web server and the ALL web browsers with an open page to that server That is the full browser instance not just the specific tab connection to the server This is the command I would use. > kill -9 (lsof -nP -t -iTCP:8080 -sTCP:LISTEN)