[Tcl-bugs] [ tcl-Feature Requests-1343161 ] exec implemenation fails to close() open file descriptors

[SourceForge.net <no...@so...>]

Feature Requests item #1343161, was opened at 2005-10-31 04:51
Message generated for change (Comment added) made by vincentdarley
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=360894&aid=1343161&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 36. File System
Group: None
Status: Open
Resolution: None
Priority: 8
Submitted By: Peter Bray (illumino)
>Assigned to: Jeffrey Hobbs (hobbs)
Summary: exec implemenation fails to close() open file descriptors

Initial Comment:
Tcl/Tk version : 8.4.6 (exists in 8.4.11)
Platform: Sun SPARC Solaris 9 

In the child section of TclpCreateProcess() in
unix/tclUnixPipe.c, after the "pid = fork(); if ( pid
....)" code, the child process sets up std file
descriptors, restores signal handling, and executes the
new process.

Unfortunately, the child leaves all existing file
descriptors open! I believe there should be an option
(perhaps the default) to close all open file
descriptors before exec() so the children (and
grandchildren,...) don't inherit them. If it is an
option then "exec" will need an interface to this
option, to allow the script writer to close all open
file descriptors.

Regards,
Peter Bray
Sydney, Australia

PS: In our case a UI, which loads a shared library that
connects to a server (TCP/IP), used "exec" to start a
backgrounded (daemonised actually) copy of firefox to
display the user help.
LSOF shows that firefox inherited the socket
connections and other file descriptors, and when the UI
exited, the firefox process still had references to
these file descriptors, meaning that the server did not
detect a connection close. Trouble ensued and memory
and cpu exited stage left... as the server try to
buffer data for a client that was not reading from its
socket connection.

----------------------------------------------------------------------

>Comment By: Vince Darley (vincentdarley)
Date: 2005-10-31 23:27

Message:
Logged In: YES 
user_id=32170

Not really my area of knowledge - it's more about processes
than it is about the filesystem.


----------------------------------------------------------------------

Comment By: Peter Bray (illumino)
Date: 2005-10-31 22:41

Message:
Logged In: YES 
user_id=426773

No, I'd call it a BUG or at least an UNDOCUMENTED FEATURE
:-), as the language provides no way to access the relevant
system calls to do the IMHO correct thing (not give away
private file descriptors) to child processes.

Without fork() & close() access, how do I stop the pollution
of child processes? I don't see it as the child executables'
responsibility to cleanup the mess created by the parent
process. In C & Perl if I fork() a child process I have the
opportunity to cleanup any open file descriptors before
issuing and exec() system call, as I should I opened them.

While I can see that additional code could be a FEATURE
REQUEST, I feel that polluting child processes is a BUG -
but each to there own opinion.



----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2005-10-31 17:19

Message:
Logged In: YES 
user_id=80530


this looks like a feature request
rather than a bug report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=360894&aid=1343161&group_id=10894