I can only get the max file descriptor number by command ulimit. But I need get the available number. Anyone can help me? Thank you very much advance.

Can you give us more details of the problem?

Do you want the number of file descriptors which are not used by a particular process? Is this process running a C program which you are writing? What?

Please give details.

Google search has quite a few article on how file descriptors work.

In /proc, each process has some file descriptor info in the directory for each specific process.

This gives some clues:

Open a file in some application
Do ps -e to get the PID
Do "ls -l /proc/<PID>/fd" This shows all the file descriptors associated with that process

I'm going to write a program which will fork numbers of processes. Each process will use 2 file descriptors(redirecting STDOUT and STDERR to 2 pipes). Before forking them, I need to detect how many available file descriptors in system for the current user, so I can know how many processes I can fork.

Thank you for your reply.

Yes, this will give all file descriptors opened in system. But how can I know how many file descriptors a user can use, for example, how many fds root can use?

Your redirection of output will be done in the child processes, yes? In that case, the limit problem is not the one you think it is.

There is no maximum number of file descriptors per "user" (i.e., root), or even per process group. So that's not your limit.

The limit problem is the number of processes you can fork. This is not a bug, it's a feature. It's meant to eliminate the possibility that a buggy program can get stuck in an infinite loop containing a fork() spree.

To examine this more closely, try this at the shell prompt:

On my system, this shows the max user processes to be 1024. I don't know whether this is the maximum processes a given user may have (no matter how spread out among parent processes), or how many fork()s may be done, or how many forks() may be done, minus one for the parent process of those fork()s. Unless someone can jump in here with the answer, you get to experiment.

I'm thinking that if you're going to use anywhere near, say, 1024 processes, you may wish to try something other than figuring out how many processes you can have, taking a deep breath, and just doing 'em all. You may wish to check each process to see whether it starts successfully before starting the next one. This provides for more robust code. It will run a little slower, but the payoff is tremendous in isolating problems that can arise either in initial debugging or in sudden changes in availability of system resources.

You might want to consider a sort of handshake system, using file record locking or something, for each process to tell the parent that it has started ok and has succeeded in getting the resources it needs.

Hope this helps a little.

I really appreciate your answer. I'm sorry I did not explain the whole things very clear. But from your answer, I can assume what's the problem in my code.

My situation is the parent process need to fork N child processes. Each children will redirect its STDOUT and STDERR to 2 pipes, while parent process will also create 2*N pipes to get the output of each child process. So from your reply, it seems the limitation is in my parent process, because each process will have no more than 1024 file descriptors. No matter how many child processes(less than 1024 by default) I forked, but the max pipe/fd number of parent process will be limited to 1024 by default. So in my program with a default ulimit config(fd number limited to 1024), actually I can only fork 511 child (because parent process has STDOUT and STDERR too. ), or maybe 510 (because parent process has STDIN.)? Is my understanding correct?

Thank again.

It looks like that will be your limit, yes.