58

Hi I have read Here that lsof is not an accurate way of getting the number of File Descriptors that are currently open. He recommended to use this command instead

 cat /proc/sys/fs/file-nr

While this command displays the number of FD's, how do you display the list of open file descriptors that the command above just counted?

dimas
  • 1,151
  • 4
  • 22
  • 33
  • 4
    You probably want to know if your ulimit is exceeded, right? I blogged about this under http://www.linuxintro.org/wiki/Is_my_ulimit_exceeded; most importantly, the ulimit is a per-process restriction that you can find under /proc/PID/limits and instead of lsof I would use ls /proc/PID/fd to list the process' file descriptors. – Thorsten Staerk May 23 '15 at 07:42

2 Answers2

71

There are two reasons lsof | wc -l doesn't count file descriptors. One is that it lists things that aren't open files, such as loaded dynamically linked libraries and current working directories; you need to filter them out. Another is that lsof takes some time to run, so can miss files that are opened or closed while it's running; therefore the number of listed open files is approximate. Looking at /proc/sys/fs/file-nr gives you an exact value at a particular point in time.

cat /proc/sys/fs/file-nr is only useful when you need the exact figure, mainly to check for resource exhaustion. If you want to list the open files, you need to call lsof, or use some equivalent method such as trawling /proc/*/fd manually.

Gilles 'SO- stop being evil'
  • 829,060
  • 1
    Hi thanks for giving a good explanation Gilles. I tried ls /proc/*/fd and got all the open fd's at that time. Its producing an output with some color coding, I'll just have to look at the manual. – dimas Feb 27 '13 at 01:40
  • 1
    @dimas /proc/*/fd directories contain symbolic links to the open files. For visual inspection, use ls -l. For automated treatment, use readlink to extract the link target. – Gilles 'SO- stop being evil' Feb 27 '13 at 01:44
  • Just use ls -l but i'll experiment with readlink. I tried other /proc/PID/maps and other options as specified here http://www.kernel.org/doc/man-pages/online/pages/man5/proc.5.html. Thanks again for the additional info. – dimas Feb 27 '13 at 01:55
  • Note that file-nr outputs the amount of allocated filedescriptors, not the actual amount of used and opened ones. – PlasmaHH May 14 '14 at 14:40
  • 1
    /proc/sys/fs/file-nr gives me 3872 (and two other numbers). How can this be the count of files I have open if ulimit -n shows me 1024? – Thorsten Staerk May 19 '15 at 12:24
  • @ThorstenStaerk file-nr is the total number of open files across the system. ulimit -n sets the maximum number of files open by each process. – Gilles 'SO- stop being evil' May 19 '15 at 12:43
  • @Gilles, do you have any reference for your statement? I looked into the man page and it explicitely states for -v that it is a per-process limitation but does NOT state this for -n. – Thorsten Staerk May 19 '15 at 12:49
  • 1
    @ThorstenStaerk All settings of setrlimit (the system call underlying the ulimit shell command) are per-process. They affect only the process that makes the call (and indirectly the processes that it later forks). – Gilles 'SO- stop being evil' May 19 '15 at 12:51
  • you are right, I verified this with a test program, pasted to http://www.linuxintro.org/wiki/Ulimit – Thorsten Staerk May 19 '15 at 15:57
29

Process information is kept dynamically by the system in directories under /proc. For example the process with PID 1234 will have a directory called /proc/1234.

There are quite a bit of information in there but right now you are interested in the /proc/1234/fd subdirectory.

NOTE: You need to have root permissions to view or open files for processes that you do not own, as well as for SetUID processes.

Example:

root@johan-HP-ProBook-6560b-LG654EA-ACQ:/proc# ls -l 2443/fd
total 0
lr-x------ 1 johan johan 64 Feb 27 10:26 0 -> pipe:[13637]
l-wx------ 1 johan johan 64 Feb 27 10:26 1 -> /home/johan/.xsession-errors
lrwx------ 1 johan johan 64 Feb 27 10:26 10 -> anon_inode:[eventfd]
lrwx------ 1 johan johan 64 Feb 27 10:26 11 -> anon_inode:[eventfd]
lrwx------ 1 johan johan 64 Feb 27 10:26 12 -> socket:[39495]
lrwx------ 1 johan johan 64 Feb 27 10:26 13 -> anon_inode:[eventfd]
lr-x------ 1 johan johan 64 Feb 27 10:26 14 -> anon_inode:inotify
lrwx------ 1 johan johan 64 Feb 27 10:26 15 -> anon_inode:[eventfd]
l-wx------ 1 johan johan 64 Feb 27 10:26 16 -> pipe:[37885]
lr-x------ 1 johan johan 64 Feb 27 10:26 17 -> pipe:[37886]
l-wx------ 1 johan johan 64 Feb 27 10:26 2 -> /home/johan/.xsession-errors
l-wx------ 1 johan johan 64 Feb 27 10:26 21 -> pipe:[167984]
lr-x------ 1 johan johan 64 Feb 27 10:26 22 -> pipe:[167985]
l-wx------ 1 johan johan 64 Feb 27 10:26 23 -> pipe:[170009]
lr-x------ 1 johan johan 64 Feb 27 10:26 24 -> pipe:[170010]
lrwx------ 1 johan johan 64 Feb 27 10:26 3 -> anon_inode:[eventfd]
lr-x------ 1 johan johan 64 Feb 27 10:26 4 -> pipe:[14726]
lrwx------ 1 johan johan 64 Feb 27 10:26 5 -> socket:[14721]
l-wx------ 1 johan johan 64 Feb 27 10:26 6 -> pipe:[14726]
lrwx------ 1 johan johan 64 Feb 27 10:26 7 -> socket:[14730]
lrwx------ 1 johan johan 64 Feb 27 10:26 8 -> socket:[13984]
lrwx------ 1 johan johan 64 Feb 27 10:26 9 -> socket:[14767]

root@johan-HP:/proc# cat 2443/fdinfo/2
pos:    1244446
flags:  0102001

Also have a look at the rest of the files under /proc ... a lot of useful information from the system resides here.

Johan
  • 4,148