Hacker News Reader

Comment by bdcravens | Hacker News Reader

Advantages over the usual command line approach? (which you can easily turn into an alias)

    kill $(lsof -t -i:8080)

View on HN

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.

True, but there's no shortage of Stack Overflow answers: https://www.google.com/search?hl=en&q=kill%20process%20on%20...

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

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.

`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/han...

Powertoys for Windows has added a "What is blocking this file?" feature recently.

https://learn.microsoft.com/en-us/windows/powertoys/file-loc...

Useful, but talk about too little too late! The fact that this is an external tool, not part of the operating system, and that you are expected to, in 2023, blindly guess which application is holding your flash drive or documents open is pretty pathetic.

> What we really need is a tool like this for Windows.

Nevermind Windows, I want an app like this for android.

I keep finding uses for more of the ls family: knew lsusb and lspci for ages, lsof is handy, and most recently I learned lsblk which is always worth using before dd'ing an image onto a disk, etc.

Back in the DOS era, there were few enough files on the system that I could just explore around and learn what everything did. That's no longer practical, but what's the alternative? There doesn't seem to be a "top 100 commands to get familiar with", or whatever. The ss64.com pages are pretty great, but...

ls /usr/bin

Choose a random entry you don't recognise and open the man page for it. There's not that many on most systems - I mean, there's likely a couple hundred or more, but some are convenience symlinks and many you'll already know.

For things you may not have by default, there's a few "awesome" lists available, like https://github.com/agarrharr/awesome-cli-apps

Hmm, tried that but that directory seems to contain ~3000 files on my old Ubuntu.

1621 on Pop, which is still about 15x more than I can reasonably remember. Hence the whole problem, it's not digestable unless you make digesting it your whole hobby. Ah well. Thanks for confirming, I guess.

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

Typical rust programmer

Typical bash programmer : https://github.com/metacritical/killport

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

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.

You could do that too. UNIX gives you a lot of options.

Do what too?

function killport() { kill $(lsof -t -i:$1) }

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.

Nice flex but what about every other person that is not a sysadmin?

They don't find themselves in the situation of sitting before a terminal emulator needing to kill a process by port in the first place?

Developers find themselves in tnis situation sometimes and are not sysadmins. I had this situation before, and I would need to google to know what lsof does and how to use it. And so do many others that are commenting positively here.

Experienced users (developer or otherwise) of unixy systems already know what lsof is. Inexperienced developers only need to learn it once, then they join the ranks of the aforementioned. Using these sort of systems for any length of time in the capacity of a developer or even just a hobby enthusiast will effectively make you a 'sysadmin', at least w.r.t. knowing the basic standard tools. Not least because lsof is useful for many sort of tasks (like figuring out which program is using a drive you're trying to umount), so chances are high that people in these situations already know about lsof.

And besides having to learn that lsof exists, you'd also have to learn that this even more obscure tool exists. And what happens if you prefer for the program to terminate itself gracefully, cleaning up whatever mess it might have made, instead of sending SIGKILL? Now you have to look up the PID or program name anyway, probably using lsof..

Get TLDR, the examples it gives almost always save me from man or google. So handy!

I'd say it's a toss-up whether the stackoverflow/chatgpt query is slower than remembering the name of the alternate tool.

Meanwhile other people are developers who only occassionally need to do this kind of thing. So they/we forget.

This is the sort of thing which Copilot on the command line is great at, actually. Copilot X is decent, too, but I prefer `copilot.vim` in my neovim plus `EDITOR=nvim` plus C-x C-e "# kill all processes listening on port 2134" which then proceeds to put it into your history and with a comment explaining it and keywording it so you can find it easier.

> Googling the stack overflow [...] every time

Don't look basic Unix stuff up on the web. Look it up in your Unix environment. The documentation is self-contained, and accessing it internally is way, way more efficient.

So instead, try one of these:

  - use `man lsof`, search 'EXAMPLES' to jump down to the examples section, and search for the word 'port'
  - search directly though examples: `tldr lsof | grep -A2 -i port`
  - look through your shell history with grep or CTRL+R
  - type the first few letters of the command and let history-based autocompletion hint the rest to you

Those options may seem strange if you're not used to them. But if you're not using techniques like that, and instead going to your web browser to look up CLI usage, you don't need to learn the CLI— you need to learn how to learn the CLI. Once you do that, a ton of things will become much easier and quicker for you to deal with.

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.

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.

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.

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

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.

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.

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.

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

The issue isn't unexperienced devs not knowing about stuff. The issue is whether devs with no experience are willing to learn new stuff or not. We all had zero experience at some point.

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.

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.

  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.

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.

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

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

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

(Heavy alias user. Why are funcions to be prefered over aliases ?)

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

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.

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

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

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.

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

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

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/

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`

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?

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

> 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

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

My point still stands about Windows, regardless.

Windows now includes the basics of GNU/Linux out of the box.

> This is why most people (and developers) still use the Windows Desktop and not the thousands of Linux Desktop(s) out there.

I'm failing to see the logic here. As a Linux user, trust me there are tons of people out there for which macOS is the only OS that exists or matters. It doesn't prevent people from switching to macOS. Years back that was true of nearly every Windows user as well (only Windows existed). I'm not understanding the causative chain here.

Reply on news.ycombinator.com