Find the number of open files

[Charles Mills]

Is there an easy way to find out the number of open files held by a
process (using C or Ruby)?
-Charlie

 

[Charles Mills]

Is there an easy way to find out the number of open files held by a
process (using C or Ruby)?

I think the way I phrased the question above makes the problem sound
harder than it is...
I am unittesting a C extension. The extension opens files using
open(). I want to make sure that the extension closes all the files it
opens (when errors occur or whatever).

So I figured getting a count of open file descriptors before the
extension code is called and after it is finished would enable me to do
this.

-Charlie

 

[Kirk Haines]

Is there an easy way to find out the number of open files held by a
process (using C or Ruby)?

There is a command, lsof, for *nix OSes that can do that.

If you don't have it, you can get it via FTP from

lsof.itap.purdue.edu:/pub/tools/unix/lsof/lsof_4.72.tar.bz2


Kirk Haines

 

[Ara.T.Howard]

Is there an easy way to find out the number of open files held by a
process (using C or Ruby)?
-Charlie

*nix only, but

man lsof
man fuser

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it.
| --Dogen
===============================================================================

 

[Robert Klemme]

I think the way I phrased the question above makes the problem sound
harder than it is...
I am unittesting a C extension. The extension opens files using
open(). I want to make sure that the extension closes all the files it
opens (when errors occur or whatever).

So I figured getting a count of open file descriptors before the
extension code is called and after it is finished would enable me to do
this.

IMHO this would not be safe unless you disable threading: another thread
could open or close files in the meantime.

Why don't you just create a customized class that does the bookkeeping?
Alternatively you could hand in open IO objects, if the logic of your
extension allows this.

Kind regards

robert

 

[Charles Mills]

*nix only, but

man lsof
man fuser

-a

Thanks for the suggestion.
I guess another way to do it would be to walk all the valid file
descriptors and call fstat() on them, checking for EBADF.
I was hoping there would a system call / library function that would do
this for me.
-Charlie

 

[Eric Schwartz]

I am unittesting a C extension. The extension opens files using
open(). I want to make sure that the extension closes all the files it
opens (when errors occur or whatever).

Call me crazy, but what's wrong with adding each file descriptor you
open into a list, and then traversing that list at error time (or
whatever) to make sure they're all closed?

So I figured getting a count of open file descriptors before the
extension code is called and after it is finished would enable me to do
this.

I'm not sure what that would buy you. If your extension code can take
a block, you're completely screwed-- that block may open new
filehandles, or close old ones, and your count-based approach would be
totally out into the weeds. Even if it doesn't, signal handlers and
other asynchronous code may open or close them without your explicit
knowledge.

Besides, knowing how many descriptors are open is a far cry from
knowing *which* descriptors are open, which is necessary to close()
them.

-=Eric

 

[Charles Mills]

IMHO this would not be safe unless you disable threading: another
thread
could open or close files in the meantime.

Good point.
The unittests are pretty simple. Basically more or less testing a C
library (not multithreaded) wrapped in Ruby.
There is a point where all Ruby data gets converted to C
types/structures and passed to the C library functions I am testing.
However, the library functions handle opening and closing files
themselves.
-Charlie

 

[Ara.T.Howard]

I think the way I phrased the question above makes the problem sound
harder than it is...
I am unittesting a C extension. The extension opens files using
open(). I want to make sure that the extension closes all the files it
opens (when errors occur or whatever).

So I figured getting a count of open file descriptors before the
extension code is called and after it is finished would enable me to do
this.

define an xopen that updates a static var - then you won't have to worry about
some other process/thread/function opening up files and killing your test...

cheerx.

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it.
| --Dogen
===============================================================================

 

[Charles Mills]

Call me crazy, but what's wrong with adding each file descriptor you
open into a list, and then traversing that list at error time (or
whatever) to make sure they're all closed?

That is a good idea.
-Charlie

 

[Charles Mills]

define an xopen that updates a static var - then you won't have to
worry about
some other process/thread/function opening up files and killing your
test...

cheerx.

-a

Yeah, if your curious that is what I am doing. The library that I am
testing already uses functions that wrap open() and close(). So I am
adding a global structure to that module to keeps track of the fd's in
use. Should be a much more robust test - keeping track of which fd's
are created using xopen and which are closed using xclose .... should
be 1 to 1.
Thanks for all the help,
Charlie

 

[Robert Klemme]

Good point.
The unittests are pretty simple. Basically more or less testing a C
library (not multithreaded) wrapped in Ruby.
There is a point where all Ruby data gets converted to C
types/structures and passed to the C library functions I am testing.
However, the library functions handle opening and closing files
themselves.

Yeah, but then how about my suggestion:

You can get the file descriptor by using IO#fileno.

If you'd uncover a bit more of your extension's functionality, we might come
up with better solutions...

Kind regards

robert