This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lcaamano
Date 2005-04-20.13:17:02
SpamBayes Score
Marked as misclassified
Logged In: YES 

Here's a reference:

The relevant post:


On 25 Feb 2001 10:48:22 GMT Casper H.S. Dik - Network 
Security Engineer <> wrote: 


Solaris at various times used a cached /dev/zero fd both for 
| thread stacks and even one for the runtime linker. 
| The runtime linker was mostly fine, but the thread library did 
| problems with people closing fds.  We since added 
MAP_ANON and no 
| longer require open("/dev/zero") .  THe caaching of fds was 
| rid of before that. 
| There are valid reasons to close all fds; e.g., if you really don't 
| want to inherit and (you're a daemon and don't care). 
| In most cases, though, the "close all" stuff performed by shells 
| and such at statup serves no purpose.  (Other than causing 
more bugs 


So the dilemma is that closing fds can cause problems and 
them open can cause problems, when a forked child does this.  
seems to tell me that hiding fds in libraries and objects is a bad 
idea because processes need to know what is safe to close 
what needs to be left open. 


If the python library had some module or global list of opened file 
descriptors, then it would be OK to expect programs to keep 
those open across fork/exec.  Something like:

 from os import opened_fds

And then it would be no problem to skip those when closing fds.  
Otherwise, your nice daemon code that deals with _urandom_fd 
will break later on when somebody caches another fd 
somewhere else in the standard library.

Also, the proposed os.daemonize() function that knows about its 
own fds would also work.

Still, the most robust solution is not to cache open fds in the 
library or perhaps catch the EBADF exception and reopen.

There are several solutions but closing this bug as invalid doesn't 
seem an appropriate one.

Date User Action Args
2007-08-23 14:30:46adminlinkissue1177468 messages
2007-08-23 14:30:46admincreate