46 lines
1.8 KiB
Plaintext
46 lines
1.8 KiB
Plaintext
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
|
|
|
|
|
|
|
|
|