APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

lsof

List Open Files.

This is much more than it sounds like. It is similar to "fuser", but has much more power. I often use it to find processes using specific network ports:



bash-2.05a$ lsof -i:22
COMMAND PID USER   FD   TYPE     DEVICE SIZE/OFF NODE NAME
ssh     397  apl    3u  inet 0x0279421c      0t0  TCP 10.0.0.14:49155->mine:ssh (ESTABLISHED)
ssh     408  apl    3u  inet 0x027944cc      0t0  TCP 10.0.0.14:49202->website:ssh (ESTABLISHED)
 

When invoked for a specific process, it will show very useful information:

bash-2.05a$ lsof -p 473
COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
vi      473  apl  cwd   VDIR   14,5    24576   143413 /Users/apl
vi      473  apl    0u  VCHR    4,4    0t844 37283460 /dev/ttyp4
vi      473  apl    1u  VCHR    4,4    0t844 37283460 /dev/ttyp4
vi      473  apl    2u  VCHR    4,4    0t844 37283460 /dev/ttyp4
vi      473  apl    3r  VREG   14,5       27  1401787 /Users/apl/t
vi      473  apl    4u  VREG   14,5        0  1440474 /private/var/tmp/vi.recover/vi.wqnCL1
vi      473  apl    5u  VREG   14,5        0  1440475 / (/dev/disk0s5)
 

I can tell from the above that I'm editing /Users/apl/t and that it is 27 bytes long. I'm logged in on ttyp4, and am sitting in /Users/apl. I can see the actual file descriptors in use also. When troubleshooting, lsof can be very handy.

"lsof" is also useful when you need to know if some other process is "done" with a file you want to do something else with. For example, some background process scp's or ftp's a file from somewhere else. You can't process it, move it, look at it, whatever until it is complete, so use lsof (or fuser) to see if any process has the file open. Often that would be some loop like this:

cd /somewhere
while :
do
	for i in *
	do
		test -e $i || break
		lsof $i || dosomethingwith $i
	done
	sleep 3
done
 

But it doesn't stop there: amazingly enough, lsof can (sometimes) help you recover a deleted file. Conditions have to be right - specifically, some process needs to have the departed loved one open and you need an OS (like Linux) that has /proc. If all that is true, then there's a link in /proc that can be copied. How would you know where that link is? Well, lsof will tell you, of course. You'd just "lsof | grep missingfile" and lsof will tell you everything you need to know about any process that has the file open: process id and file descriptor (fd).

So let's say I'd just stupidly removed ~/IMPORTANT and instantly realized that, duh, it's IMPORTANT. What can I do? If I immediately do "lsof ~/IMPORTANT", I see I'm in luck:

COMMAND   PID USER   FD   TYPE DEVICE SIZE    NODE NAME
less    10971 root    4r   REG    3,2   29 2785343 /root/IMPORTANT
 

I now know that there is a symbolic link in /proc/10971/fd/4:

# ls -l /proc/10971/fd/4
lr-x------    1 root     root           64 Nov 30 06:35 /proc/10971/fd/4 -> /root/IMPORTANT
 

So I can "cp /proc/10971/fd/4 ~/IMPORTANT" and all is well. How often is this going to save your bacon? Not very often, but it's worth a shot. Realistically, in most cases this won't help. Nothing will have your file open and you would need to take more drastic measures.



Got something to add? Send me email.





Increase ad revenue 50-250% with Ezoic


More Articles by

Find me on Google+

© Tony Lawrence



Kerio Samepage


Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us





C++ is a badly designed and ugly language. It would be a shame to use it in Emacs. (Richard Stallman)

Sooner or later everyone sits down to a banquet of consequences. (Robert Louis Stevenson)












This post tagged: