From: donn at u.washington.edu (Donn Cave)
Date: 12 Apr 1999 17:38:45 GMT
Subject: forking + stdout = confusion
References: <RUgQ2.31$Oq4.32657@newsfeed.avtel.net> <7jlnfyowd3.fsf@gandalf.midearth.fuzzys.org>
Message-ID: <7etb35$16v2$1@nntp6.u.washington.edu>
Content-Length: 1482
X-UID: 1685                                                  

Julien Oster <fuzzy at fuzzys.org> writes:
...
| I ran in exactly the same problem. I tried closing all stdxxx-filedescriptors,
| setting a new session id with setsid, also tried it with setting a new
| progress groups, and I even tried to reopen stdin, stderr and stdout to
| /dev/null, but nothing helped. Then I saw that in OpenBSD, there's a function
| in stdlib.h called "daemon()". You simply call it, and it puts the running
| program in the background (it forks and exits the parent), redirects the
| stdxxx-descriptors, sets a new session ID etc... and with this function, it
| works!

I wonder if you could get the effect by iteratively closing all potential
file descriptors?  This is a pretty common sight in service daemon programs.
In Python it's a little more awkward because you have to guess the range
of possible descriptors, which a C program could get from getdtablesize().

   wereopen = []
   for i in range(128):
       try:
           os.close(i)
           wereopen.append(i)
       except os.error:
           pass
   fp = open('log', 'w')
   fp.write('closed units %s\n' % repr(wereopen))

The other things I've seen daemon() do are basically Berkeley terminal
driver issues, to drop the controlling terminal and isolate the program
from the job control session that started it -- not relevant there, since
the HTTP service daemon didn't start it that way.

	Donn Cave, University Computing Services, University of Washington
	donn at u.washington.edu




