N
nisimura
Hi,
I noticed that when I used SocketServer.ForkingMixIn
(ForkingTCPServer), there were always zombie processes around. I
searched for where waitpid() is called in ForkingMixIn and found it in
SocketServer.py:
def process_request(self, request, client_address):
"""Fork a new subprocess to process the request."""
self.collect_children()
pid = os.fork()
if pid:
# Parent process
if self.active_children is None:
self.active_children = []
self.active_children.append(pid)
self.close_request(request)
return
else:
# Child process.
# This must never return, hence os._exit()!
try:
self.finish_request(request, client_address)
os._exit(0)
except:
try:
self.handle_error(request, client_address)
finally:
os._exit(1)
So waitpid() is called just before fork(). This means that if next
request does not come in, zombie processes are not reclaimed forever!
Is this an intentional behavior? Is there any workaround?
I noticed that when I used SocketServer.ForkingMixIn
(ForkingTCPServer), there were always zombie processes around. I
searched for where waitpid() is called in ForkingMixIn and found it in
SocketServer.py:
def process_request(self, request, client_address):
"""Fork a new subprocess to process the request."""
self.collect_children()
pid = os.fork()
if pid:
# Parent process
if self.active_children is None:
self.active_children = []
self.active_children.append(pid)
self.close_request(request)
return
else:
# Child process.
# This must never return, hence os._exit()!
try:
self.finish_request(request, client_address)
os._exit(0)
except:
try:
self.handle_error(request, client_address)
finally:
os._exit(1)
So waitpid() is called just before fork(). This means that if next
request does not come in, zombie processes are not reclaimed forever!
Is this an intentional behavior? Is there any workaround?