hurf@theory.tn.cornell.edu (Hurf Sheldon) (02/27/91)
One of my users asks:
Hurf,
is there a Unix system call (or some other method) for
finding out how many file descriptors a process has
open?
I can't seem to find anything readily available - the kernal
must keep this info as part of the per process stats. My
man -k doesn't come up with anything and some other rooting
around was similarly fruitless. I have seen some monitor
programs have these stats but how do you access it. I would
be interested in info on any version of unix - our specific
environments are risc-Ultrix 4.xx and HP-UX 7.xx
Thanks,
hurf
--
Hurf Sheldon Network: hurf@theory.tn.cornell.edu
Program of Computer Graphics Phone: 607 255 6713
580 Eng. Theory Center, Cornell University, Ithaca, N.Y. 14853 jik@athena.mit.edu (Jonathan I. Kamens) (02/28/91)
I assume that you mean you want to find out from outside the particular process. If you're inside it, you can do something like run fchmod or fstat on each file descriptor and count the number that succeed -- that's the number of valid file descriptors for that process (well, actually, you have to add to that the number that fail because of errors other than EBADF). From outside the process, you have to grovel in kernel memory, although some flavors of Unix provide things like /dev/proc that allow you access to a device that you can pull process information from. I think SunOS has a library of function calls whose names start with kvm_ that allow you to dig around the kernel. A good way to find out how to do this on many different systems would probably be to get your hands on the source code for "ofiles" and stare at it for a while. Ofiles does this, so you should be able to figure out how. Ofiles is available in volume 18 of the comp.sources.unix archives (make sure you get ofiles,new, not ofiles). -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
gwyn@smoke.brl.mil (Doug Gwyn) (02/28/91)
In article <1991Feb26.213145.26540@batcomputer.tn.cornell.edu> hurf@theory.tn.cornell.edu (Hurf Sheldon) writes: > is there a Unix system call (or some other method) for > finding out how many file descriptors a process has > open? This is another one of the "why would you possibly care?" category of questions. There is no direct support for this, but something of possible use would be to see what value dup(0) returns (then close() the duplicate FD). You will get the lowest available FD number, which may be sufficient. By elaborating on this idea you could also count the FDs initially in use, but why would you want to?
henry@angel.Eng.Sun.COM (Henry McGilton) (02/28/91)
In article <15346@smoke.brl.mil>, gwyn@smoke.brl.mil (Doug Gwyn) writes: > In article <1991Feb26.213145.26540@batcomputer.tn.cornell.edu> hurf@theory.tn.cornell.edu (Hurf Sheldon) writes: ** is there a Unix system call (or some other method) for ** finding out how many file descriptors a process has open? * This is another one of the "why would you possibly care?" category * of questions. There is no direct support for this, but something * of possible use would be to see what value dup(0) returns (then * close() the duplicate FD). You will get the lowest available FD * number, which may be sufficient. By elaborating on this idea you * could also count the FDs initially in use, but why would you want to? Back in the bad old days of SunView, window applications used two fd's per subwindow (plus many more fd's for other things. Because of the limit of 32 open files per process (later upped to 64 in SunOS 4.0), SunView window applications with lots of subwindows could potentially run out of fd's. What we had to do was some kind of window garbage collection, plus checking that there were enough fd's available before trying to create a new window and crashing if we could not. So we wrote this little bit of code to count the number of available fd's: { struct stat statb; register int i, n = 0; extern int errno; for (i = getdtablesize() - 1; i >= 0; i--) if (fstat(i, &statb) < 0 && errno == EBADF) n++; } Mind you, it only works on systems supporting getdtablesize. ........ Henry
mike@bria.commodore.com (02/28/91)
In an article, theory.tn.cornell.edu!hurf (Hurf Sheldon) writes: >is there a Unix system call (or some other method) for >finding out how many file descriptors a process has >open? Well, the *real* way to do this is to go munging through the kernel's process table. :-) Actually, you could do something like this: #define MAXFD 100 /* or some reasonable number */ getnumfd() { int i = 0, num = 0; struct stat buf; while ( i < MAXFD ) if ( fstat(i++,&buf) == 0 ) ++num; return num; } Kind of ugly, but it could get the job done. The only drawback is that the MAXFD value may be unrealistic after a few "relinkings of the kernel." Cheers, -- Michael Stefanik, MGI Inc., Los Angeles| Opinions stated are not even my own. Title of the week: Systems Engineer | UUCP: ...!uunet!bria!mike ------------------------------------------------------------------------------- Remember folks: If you can't flame MS-DOS, then what _can_ you flame?
eonu24@castle.ed.ac.uk (I Reid) (03/01/91)
In article <487@bria>: >In an article, theory.tn.cornell.edu!hurf (Hurf Sheldon) writes: >>is there a Unix system call (or some other method) for >>finding out how many file descriptors a process has >>open? >Well, the *real* way to do this is to go munging through the kernel's >process table. :-) Why go to all this trouble when there is a system call to do it (at least in BSD... don't know about anywhere else). Here's a bit of code showing it. _____________________________________________________________________________ #include <stdio.h> main () { int nds,mds,a; mds = getdtablemax (); nds = getdtablesize (); printf ("There are %d descriptors (%d maximum) in use at the moment.\n",mds,nds); } _____________________________________________________________________________
mike@bria (03/02/91)
In an article, castle.ed.ac.uk!eonu24 (I Reid) writes: >>Well, the *real* way to do this is to go munging through the kernel's >>process table. :-) > >Why go to all this trouble when there is a system call to do it (at >least in BSD... don't know about anywhere else). Here's a bit of code >showing it. Repeat after me ... "All the world is not BSD. All the world is not BSD. All the world is not BSD. All the world is not BSD ..." Cheers, -- Michael Stefanik, MGI Inc., Los Angeles| Opinions stated are not even my own. Title of the week: Systems Engineer | UUCP: ...!uunet!bria!mike ------------------------------------------------------------------------------- Remember folks: If you can't flame MS-DOS, then what _can_ you flame?
tchrist@convex.COM (Tom Christiansen) (03/02/91)
From the keyboard of uunet!bria!mike:
:In an article, castle.ed.ac.uk!eonu24 (I Reid) writes:
:>Why go to all this trouble when there is a system call to do it (at
:>least in BSD... don't know about anywhere else).
:
:Repeat after me ...
:
: "All the world is not BSD. All the world is not BSD. All the
: world is not BSD. All the world is not BSD ..."
Yes, but that's their own fault. :-)
As Chris Torek recently pointed out, pure BSD runs on just a few
machines. But if you count all the machines that have some kind of BSD
compatibility or library, you've got quite a few. Just to name one, how
many Suns are there out there, eh? And what about Ultrix? They started
out BSD derived; whilel I've heard they've been going for SysVish lately,
I find it hard to believe that they would get away with tossing out
existing functionality. Does getdtablesize() still work on the latest
version of Ultrix?
--tom
--
"UNIX was not designed to stop you from doing stupid things, because
that would also stop you from doing clever things." -- Doug Gwyn
Tom Christiansen tchrist@convex.com convex!tchristguy@auspex.auspex.com (Guy Harris) (03/03/91)
>Why go to all this trouble when there is a system call to do it (at >least in BSD... Because there *isn't* such a call in BSD. There's no "getdtablemax()" in 4.3-reno or previous releases. Maybe you have some Mutant BSD From Hell with "getdtablemax()", but if so, your system isn't representative....