Close all file descriptors

  • Permalink
  • submit to reddit
  • Email
  • Follow


How do i close all the open file descriptors, without knowing how many
descriptors are open.
Is it not bad to close a file descriptor which is not open.

0
Reply ravi 7/25/2004 6:57:33 AM

See related articles to this posting

ravi wrote:
> How do i close all the open file descriptors, without knowing how many
> descriptors are open.
> Is it not bad to close a file descriptor which is not open.

man getdtablesize

Use this information to go over al descriptors between 0 (or 3)
and the value returned by getdtablesize() call.

-- 
Lev Walkin
vlm@lionet.info
0
Reply Lev 7/25/2004 7:08:29 AM

On Sun, 25 Jul 2004 00:08:29 -0700, Lev Walkin wrote:

> ravi wrote:
>> How do i close all the open file descriptors, without knowing how many
>> descriptors are open.
>> Is it not bad to close a file descriptor which is not open.
> 
> man getdtablesize
> 
> Use this information to go over al descriptors between 0 (or 3)
> and the value returned by getdtablesize() call.

Baad programming habits.

Much better to keep track of what you've opened, or use clone().
0
Reply Viktor 7/25/2004 12:54:13 PM

Viktor Lofgren wrote:
> On Sun, 25 Jul 2004 00:08:29 -0700, Lev Walkin wrote:
> 
> 
>>ravi wrote:
>>
>>>How do i close all the open file descriptors, without knowing how many
>>>descriptors are open.
>>>Is it not bad to close a file descriptor which is not open.
>>
>>man getdtablesize
>>
>>Use this information to go over al descriptors between 0 (or 3)
>>and the value returned by getdtablesize() call.
> 
> 
> Baad programming habits.
> 
> Much better to keep track of what you've opened, or use clone().

If we're talking about programming practices, it might be even better
to use fcntl(, F_SETFD, &FD_CLOEXEC), in cases where exec() is planned
down the road.

However, neither "tracking what you've opened", nor "habitually setting
close-on-exec flag" are universally applicable in the real world programming.
The things is, many libraries (including libc) open file descriptors
"behind the scenes". If a program does not depend on any third-party
libraries and does not use certain libc functions (such as
openlog(3)/syslog(3), getpwnam(3), etc), then yes, keeping track is key.
Otherwise, just closing every possible file descriptor is just plain
better than closing certain ones which are accounted for, and hoping that
accounting was right and no other library opened shadow fds behind
the scenes.

-- 
Lev Walkin
vlm@lionet.info
0
Reply Lev 7/25/2004 1:16:14 PM

On Sun, 25 Jul 2004, Viktor Lofgren wrote:

> Much better to keep track of what you've opened, or use clone().

Clone is not portable.

-- 
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
0
Reply Rich 7/25/2004 7:45:22 PM

On Sat, 24 Jul 2004, ravi wrote:

> How do i close all the open file descriptors, without knowing how many
> descriptors are open.

If you're on a recent version of Solaris, closefrom() will
do what you want.

> Is it not bad to close a file descriptor which is not open.

Nope.  The worst that will happen is that you'll waste a few
ms of CPU time trying to close files that are not open.

-- 
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
0
Reply Rich 7/25/2004 7:47:20 PM
comp.unix.programmer 10601 articles. 64 followers. Post

5 Replies
345 Views

Similar Articles

[PageSpeed] 8

  • Permalink
  • submit to reddit
  • Email
  • Follow


Reply:

Similar Artilces:

closing file descriptors
Here's a question I never thought I'd have to ask -- how do I close a file descriptor opened via IO.sysopen ? -mental On Apr 24, 2007, at 5:45 PM, MenTaLguY wrote: > Here's a question I never thought I'd have to ask -- how do I close > a file descriptor opened via IO.sysopen ? IO.new(IO.sysopen(path)).close Seems a bit round-about though. Gary Wright ...

how to close a file descriptor ?
Hello all I must develop an application where I create a file descriptor with open(), then I write some data into the file with write() and then I close the file with close(). The documentation of close() says that there can by errors during this operation. For me it is not important if there is an i/o error or if close fails because there is no space left on the device. It is not important if I loose data during the close operation. For me it is important to close the file handle - to deallocate it. How can I close the file descriptor (I mean to deallocate it) if close...

How to close a file descriptor ?
Hello all I must develop an application where I create a file descriptor with open(), then I write some data into the file with write() and then I close the file with close(). The documentation of close() says that there can by errors during this operation. For me it is not important if there is an i/o error or if close fails because there is no space left on the device. It is not important if I loose data during the close operation. For me it is important to close the file handle - to deallocate it. How can I close the file descriptor (I mean to deallocate it) if close...

Close file descriptor
Hi: The following function intends to close the given fd. After function returned, fd associates to no system resource. Is it correct? int my_close(int fd) { for(;;) { if(close(fd)==0) { return(0); } switch(errno) { case EBADF: return(EBADF); case EIO: return(EIO); /* fd assciates to no resource? */ case EINTR: break; /* try close(fd) again. ok? */ default: return(errno); /* not expected to reach here */ }; } } IJ. Wang wij@seed.net.tw wrote: > Hi: > > The following function ...

how to close a stalled file descriptor?
I'm having trouble closing a file descriptor on a stalled named pipe. To unblock myself if the write takes too long because the pipe is full and there is no reader on the other end of the pipe, I put in place a signal handler. But if the signal handler is invoked and I regain control, on any subsequent attempt to close the file descriptor, it stalls again! How do I force the file descriptor to close so I don't have an infinite buildup of file descriptors in my process, if I want to continue operating? Even a simple "die" or "exit" won't work because it tries ...

closing all open file descriptors
i just discovered a subtle bugette (no harm done except nfs silly name created) in some code i had written that is caused by forking with open file descriptors followed by a close/unlink in the parent. the child never uses the file and so it's not really an 'error' - but on nfs this will cause a sillyname to appear (.nfsxxxxxxxx) and remain until the child exits which, in this case, can be up to five days later and i have dozens of these guys cluttering up my directories since this code runs on dozens of machine simoutaneously. i'm wondering - is there some way in ruby to ob...

How to close roque file descriptors?
Let's say a program opens a bunch of file handles and then dies non-gracefully, leaving this(on a linux box): bash-2.05$ /sbin/sysctl fs.file-nr fs.file-nr = 65536 64352 65536 Is there a way to close all those file descriptors without rebooting? Previously, I thought that exiting the parent shell would close them, but I was wrong... Kyndig <kyndig@unixpowered.org> wrote: > Let's say a program opens a bunch of file handles and then dies > non-gracefully, leaving this(on a linux box): > > bash-2.05$ /sbin/sysctl fs.file-nr > fs.file-nr = 6553...

Closing socket file descriptors
Hi, I'm experiencing a problem when trying to close the file descriptor for a socket, creating another socket, and then closing the file descriptor for that second socket. I can't tell if my issue is about Python or POSIX. In the following, the first time through, everything works. On the second connection, though, the same file descriptor as the first connection may be re-used, but for some reason, trying to do os.read/close on that file descriptor will cause an error. Thanks in advance for any help on why this problem is occurring and/or how to resolve it (preferrably, I ca...

How to close rogue file descriptors?
Let's say a program opens a bunch of file handles and then dies non-gracefully, leaving this(on a linux box): bash-2.05$ /sbin/sysctl fs.file-nr fs.file-nr = 65536 64352 65536 I was under the impression that when a process dies, all descriptors are freed by the kernel; but I must be wrong. Is there a way to close all those file descriptors without rebooting? kyndig@unixpowered.org (Kyndig) wrote in message news:<4a8a6f54.0309090634.8e441b7@posting.google.com>... > Let's say a program opens a bunch of file handles and then dies > non-gracefully, leaving...