Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Unix Utility to Know About: lsof (2009)

catonmat.net

Post reply on HN
Print view View original

41–50 of 54 posts

Re: A Unix Utility to Know About: lsof (2009)

#41

Post by smhenderson »

devonkim wrote: post #34
johnchristopher wrote: post #7

Earlier quoted context omitted.

I am guilty of using `ps|aux` for the sole purpose of answering this question: Is it (still) running ? edit: `ps aux|grep`, indeed. Silly me in the early hours of a rest day :).

Modern Linuxes have pgrep to help avoid the inevitable "lol, the grep process I fired will match" issue that results in having to filter that out as well with yet another program.

Yeah, I always felt having to type the extra bit was strange, like maybe grep could have a switch to say "don't find grep" but I guess having a switch for such a specific use case, grepping processes, is overkill.

Anyway, it's just a reflex now to always:

  ps aux | grep  | grep -v grep

Re: A Unix Utility to Know About: lsof (2009)

#42

Post by LukeShu »

_c_ wrote: post #30

s/Unix/Linux/ The following can be adapted to provide other information: whatever procfs provides. This is a rough equivalent of "pgrep -fl .|less". Work-in-progress . Don't know if Linux grep has "-a" option. #! /bin/sh # Almquist clone, not Bash case $# in 0) exec grep -a . proc/[0-9]*/cmdline \ |exec tr '\000' '\040' \ |exec sed ' /grep -a .* proc/d; #parent: '"$$"'; s/proc./ /; s/\/cmdline:/ /; ' \ |exec less ;;…

You don't need any of those `exec`s. Yes, GNU grep has `-a`.

If you don't like the backslash-newline-pipe sequence, if you put the pipe at the end of the previous line, you don't need the backslash; but it's less obvious that the next line is operating on the output of the previous.

Multi-line arguments to sed can be a pain (good luck getting your editor to auto-indent them). Instead, you can use -e to specify multiple sed commands.

There's nothing in there that would make it not work in bash. That should work in any Bourne-family shell.

It only handles 0 or 1 arguments correctly, not > 1.

Re: A Unix Utility to Know About: lsof (2009)

#43

Post by cmiller1 »

amyjess wrote: post #27

lsof is my go-to command for "why won't this drive unmount?". That alone makes it incredibly useful. Also, back in the bad old days, 'lsof | grep snd' helped track down what the hell was hogging my sound card (setting up proper mixing has made that a distant memory, though).

lsof | grep Trash is super useful on os x when Finder refuses to empty the trash because some process is holding onto one of the files.

Re: A Unix Utility to Know About: lsof (2009)

#44

Post by nocman »

devonkim wrote: post #34
johnchristopher wrote: post #7

Earlier quoted context omitted.

I am guilty of using `ps|aux` for the sole purpose of answering this question: Is it (still) running ? edit: `ps aux|grep`, indeed. Silly me in the early hours of a rest day :).

Modern Linuxes have pgrep to help avoid the inevitable "lol, the grep process I fired will match" issue that results in having to filter that out as well with yet another program.

One problem with pgrep is it has no option to ignore case.

Yes, I do sometimes have processes with camel-cased names which I may or may not remember exactly. So you:

  ps auwx | grep -i {lc-version-of-camel-cased-name}

Re: A Unix Utility to Know About: lsof (2009)

#45

Post by alinspired »

corford wrote: post #36

lsof -i -n -P is a regular "reflex" command whenever I'm trying to figure out why a daemon I've just setup isn't responding to requests (immediately answers the questions: is it running? and, if yes, under what privs? and on what interface?). That together with a dump of active iptables rules normally results in an immediate fix for 90% of "why can't I connect to X" problems :)

had to try this lsof to see it's essentially `netstat -atpu`

Re: A Unix Utility to Know About: lsof (2009)

#46

Post by amyjess »

smhenderson wrote: post #41
devonkim wrote: post #34

Earlier quoted context omitted.

Modern Linuxes have pgrep to help avoid the inevitable "lol, the grep process I fired will match" issue that results in having to filter that out as well with yet another program.

Yeah, I always felt having to type the extra bit was strange, like maybe grep could have a switch to say "don't find grep" but I guess having a switch for such a specific use case, grepping processes, is overkill. Anyway, it's just a reflex now to always: ps aux | grep | grep -v grep

You can also surround each character in the program's name with square brackets.

    ps -ef | grep [p][r][o][g][r][a][m]

Re: A Unix Utility to Know About: lsof (2009)

#47

Post by jpitz »

amyjess wrote: post #46
smhenderson wrote: post #41

Earlier quoted context omitted.

Yeah, I always felt having to type the extra bit was strange, like maybe grep could have a switch to say "don't find grep" but I guess having a switch for such a specific use case, grepping processes, is overkill. Anyway, it's just a reflex now to always: ps aux | grep | grep -v grep

You can also surround each character in the program's name with square brackets. ps -ef | grep [p][r][o][g][r][a][m]

You only need surround one character.

Re: A Unix Utility to Know About: lsof (2009)

#48

Post by jupiter2 »

voidz wrote: post #2

`lsof` and `ps` have the most dense man pages I have ever tried to plow through, and that's causing me to use these tools only at a minimum.

> `lsof` and `ps` have the most dense man pages I have ever tried to plow through

That's why I was so happy to stumble across pstree the other day. Even the man page is excellent! Every now and again, I'll come across a util like this that I can put into immediate action w/o lots of deciphering. pstree -a is awesome for a relative newbie like me.

Re: A Unix Utility to Know About: lsof (2009)

#49

Post by Terr_ »

smhenderson wrote: post #23
nailer wrote: post #5

For finding what uses a file, I'm an 'fuser' kid but lsof is fine too. Using posh right now, so had to make my own: function fuser($relativeFile){ $file = Resolve-Path $relativeFile foreach ( $Process in (Get-Process)) { foreach ( $Module in $Process.Modules) { if ( $Module.FileName -like "$file*" ) { $Process | select id, path } } } } In use: > fuser .\node_modules\ Id Path -- ---- 2660 C:\Program Files\nodejs\node.…

I find myself using lsof for it's ability to show me what TCP sockets are in use more than what actual files are open. lsof | grep TCP

For that I often use:

netstat --ip -a -p

Those particular options mean to show just IP ports (UDP/TCP), in all statuses (active, listening) and to display the local process which is involved.

Re: A Unix Utility to Know About: lsof (2009)

#50

Post by _c_ »

LukeShu wrote: post #42
_c_ wrote: post #30

s/Unix/Linux/ The following can be adapted to provide other information: whatever procfs provides. This is a rough equivalent of "pgrep -fl .|less". Work-in-progress . Don't know if Linux grep has "-a" option. #! /bin/sh # Almquist clone, not Bash case $# in 0) exec grep -a . proc/[0-9]*/cmdline \ |exec tr '\000' '\040' \ |exec sed ' /grep -a .* proc/d; #parent: '"$$"'; s/proc./ /; s/\/cmdline:/ /; ' \ |exec less ;;…

You don't need any of those `exec`s. Yes, GNU grep has `-a`. If you don't like the backslash-newline-pipe sequence, if you put the pipe at the end of the previous line, you don't need the backslash; but it's less obvious that the next line is operating on the output of the previous. Multi-line arguments to sed can be a pain (good luck getting your editor to auto-indent them). Instead, you can use -e to specify multip…

Thanks for taking the time to comment.

Multiple arguments could be added if you want that. I personally do not need it as I search the cmdline patterns I need without using spaces. I use dots instead. Quick and dirty.

I write 100's of these small scripts for my own use only so I have my own style, peculiar as it may be. I never need indentation because I always keep scripts short; I only use it occasionally and randomly.

I do not use -e with sed, unless I'm using branches or loops.

The execs seem superfluous but actually make a difference, at least on the UNIX I use. Try it with and without and see if you notice.

All my scripts are portable to Bash, but they're also portable to the most basic of Bourne-compatible shells too. I do not use Bash.

Post reply on HN