LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (http://www.linuxquestions.org/questions/linux-software-2/)
-   -   File Descriptors and Ulimits (http://www.linuxquestions.org/questions/linux-software-2/file-descriptors-and-ulimits-572091/)

ALInux 07-25-2007 03:36 AM

File Descriptors and Ulimits
 
Dear All
I have a couple of questions regarding file descriptors (handles) and the command ulimit.
Now the thing is I know about Ulimit..to get a snapshot about the file descriptors on the system I executed the following command :


[root@localhost mail]# cat /proc/sys/fs/file-nr
2520 0 206068
| | |
| | |
| | maximum open file descriptors permitted
| total free allocated file descriptors
total allocated file descriptors since boot

I took the appended descriptions from http://support.zeus.com/zws/faqs/200...iledescriptors
What I do not understand is that how these number are calculated if the total number of allocators since boot is 2520 and the available is 0 how can the
maximum open file descriptors permitted be bigger than that number?
I mean if the first number is used to describe the file allocators of one process in particular which is it ?

Another thing that confused me from the same article is the following phrase :

"In current (2.4+) Linux kernels, file descriptors are dynamically
created as necessary, but cannot be removed or reduced other than by
rebooting the server."

What does that mean, that in 2.4 kernels and above (I am using 2.6) file descriptors hang on to the process untill the system is rebooted..I think there is either something wrong with the way I understood this or ....

Can anyone shed some light on the issues mentioned above please ?

wjevans_7d1@yahoo.co 07-25-2007 07:46 AM

The third number, the maximum number of file descriptors permitted, does not change while the system is running.

It isn't usually the case that this maximum number of file descriptors have all been allocated. That's why the first number is usually much smaller than the third number. New file descriptors are allocated as needed.

Let's say a process requests a file descriptor (by opening a file). Let's suppose that the second number, the total number of file descriptors which have already been allocated but are not currently being used, is greater than 0. Then one of these will be used for this request, and the first number (the number of allocated file descriptors) will not change, because a new file descriptor did not need to be allocated for this request. Instead, the second number would decrease by 1.

But let's suppose instead that the second number is 0. This would mean that all file descriptors which have been allocated are currently in use. In that case, the second number would be already be zero, so the OS doesn't decrease it by 1. Instead, the OS allocates a new file descriptor, and increases the first number by 1.

The OS never deallocates a file descriptor while it's running. When a process closes a file descriptor, that file descriptor becomes available for either the same process (while it exists) or another process. So it doesn't "hang on" to the process until reboot.

Try this shell script on a system that's quiet, that's not running very much:

Code:

#!/bin/bash

cat /proc/sys/fs/file-nr
cat /proc/sys/fs/file-nr < /dev/null
cat /proc/sys/fs/file-nr

When I tried it, I got these numbers:

Code:

1242    363    13107
1242    362    13107
1242    363    13107

See? When the shell script closed /dev/null, the second number increased by 1, and the file descriptor was made available for any process for use.

Hope this helps.


All times are GMT -5. The time now is 04:22 PM.