Home

How Many Open Files?

Fri, 2009.01.30 - 18:54 — müzso
http://www.netadmintools.com/art295.html
We knew the answer to this question once, back when the world was young and full of truth. Without hesitation, we'd have spouted "Just take the output of lsof | wc -l!" And it's true enough, in a general sort of way. But if you asked me the same question now, my answer would be: "Why do you want to know?"

Are you, for instance, attempting to determine whether the number of open files is exceeding the limit set in the kernel? Then the output of lsof will be practically useless.
(...)

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Fri, 2009.01.30 - 22:12 — airwin

Obfuscated

No. Open files means files that were accessed wit open(2). lsof also shows additional vnodes that are used by the process, like the program text image and shared library mappings, current directory and root directory. The process has limited control over these - especially none over mapped obejcts. These are bound to the AS after the parent calls fork() and before main(). Most important the process cannot close(2) these files.

On the other hand the proc filesystem exposes these, too. For example program object are listed under /proc/<pid>/object.

Fri, 2009.01.30 - 22:29 — müzso

Re: Obfuscated

I think if we're going that much into the details, the term "open files" does not tell anything in itself about who or what opened that file. It just means files that are opened at the moment. Smile The writer of that article did not assume that the process would have any control over all "open files" listed by lsof.
He even wrote in the last paragraph: "Quite a difference. This process has only four open file descriptors, but there are thirty open files associated with it. Some of the open files which are not using file descriptors: library files, the program itself (executable text), and so on as listed above. These files are accounted for elsewhere in the kernel data structures (cat /proc/PID/maps to see the libraries, for instance), but they are not using file descriptors and therefore do not exhaust the kernel's file descriptor maximum."

And more over: "What is an open file?
Is an open file a file that is being used, or is it an open file descriptor? A file descriptor is a data structure used by a program to get a handle on a file, the most well know being 0,1,2 for standard in, standard out, and standard error. The file-max kernel parameter refers to open file descriptors, and file-nr gives us the current number of open file descriptors. But lsof lists all open files, including files which are not using file descriptors - such as current working directories, memory mapped library files, and executable text files."

I think that both of you know exactly what you're talking about and both of you share and agree on the same knowledge. The difference is simply terminology. He considers a file "open" even if it was opened by the kernel (btw. ... I assume even shared libraries, program text image, etc. are opened by the kernel using open(2) Wink ) and not by a given (user space) process. And eg. lsof lists all those additional files for a process, because they are indeed "associated" since the process needs them in order to work properly.

I think the point of the article was to enlighten and not to "obfuscate". Shock

Fri, 2009.01.30 - 23:19 — airwin

Okay, then just let's stick

Okay, then just let's stick to the terminology used by kernel developers. Smile

Sat, 2009.01.31 - 14:41 — müzso

Re: Okay, then just let's stick

Kernel developers? Making up 0.001% of linux/unix users? Wink Making up 0.000001% of computer users?
I'm sure their terminology is the least understood in the world.
But hey: it's a free world. Everybody can have their own understanding of the "open files" term. Just don't judge people too early based on their definition. Wink