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 ?
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 ?
Seems a bit round-about though.
...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
i'm wondering - is there some way in ruby to ob...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?
firstname.lastname@example.org (Kyndig) wrote in message news:<email@example.com>...
> Let's say a program opens a bunch of file handles and then dies
> non-gracefully, leaving...how to find and close opened file descriptor
During my testing, I found that ruby doesn't create IO object for each
opened file descriptor which are inherited from parent process. So we
have to close all these opened file descriptor except stdin, stdout and
stderr by following way:
3.upto(1023) do |fd|
if io = IO::new(fd)
But I really don't like this way. Is there better way that I can find
all opened file descriptors.
And now I am assuming the maximum file no is 1023. Is there any way that
I can get the maximum file no?
On my Solaris system, the man page for "exec" says the following:
With the exec built-in, if arg is given, the command speci-
fied by the arguments is executed in place of this shell
without creating a new process. Input/output arguments may
appear and affect the current process. If no arguments are
given the effect of this command is to modify file descrip-
tors as prescribed by the input/output redirection list. In
this case, any file descriptor numbers greater than 2 that
are opened with this mechanism are clos...close file descriptor 0,1,2
I'm observing the following behavior in one of our systems. It has a
close(0) call to close file descriptor 0. This eventually caused some
trouble to our system, due to my second question below. So, can
someone shed lights on:
1) is it ever legitimate to close(0) or close(1) or close(2)?
2) I did some experiments and found out that once I have close(0),
next open call will think 0 is a valid descriptor and start assigning
this to open calls. Is this expected?
On Thu, 12 Apr 2012 18:45:40 -0700, DE wrote:
> 1) is it ever legitimate to close(0) or close(1) or close(2)?
And t.../bin/su closes open file descriptors ?
It seems that an AIX open file descriptor is not preserved across /bin/su.
I have a program that opens a file, then passes that file's file
descriptor to an exec'ed program with a command line argument. The
exec'ed program reads directly from that fd. No problem here, as file
descriptors are kept open across exec() calls.
But when I put /bin/su in between the calling and called program,
the called program gets errno 9 (Bad file descriptor) when
attempting to read. I guess somebody along the way (either su or sh)
has closed the file. I thought that perhaps a range of low fd's...