Copterfly / modwsgi

Automatically exported from code.google.com/p/modwsgi
0 stars 0 forks source link

Code dependent on popen() failing in mod_wsgi daemon processes. #38

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
On FreeBSD, plus Ubuntu and RedHat Linux (but NOT Mac OS X), code dependent
on popen() is failing in mod_wsgi daemon processes.

For example, for code:

from commands import getoutput
def application(environ, start_response):
   status = '200 OK'
   output = getoutput('uptime')
   response_headers = [('Content-type', 'text/plain'),
                       ('Content-Length', str(len(output)))]
   start_response(status, response_headers)
   return [output]

this will fail with:

[Tue Oct 16 15:51:17 2007] [info] mod_wsgi (pid=23422): Create
interpreter '127.0.1.1|/wsgi/commands.py'.
[Tue Oct 16 15:51:17 2007] [info] [client 127.0.0.1] mod_wsgi
(pid=23422, process='grahamd',
application='127.0.1.1|/wsgi/commands.py'): Loading WSGI script
'/home/grahamd/scripts/wsgi/commands.py'.
[Tue Oct 16 15:51:17 2007] [error] [client 127.0.0.1] mod_wsgi
(pid=23422): Exception occurred processing WSGI script
'/home/grahamd/scripts/wsgi/commands.py'.
[Tue Oct 16 15:51:17 2007] [error] [client 127.0.0.1] Traceback (most
recent call last):
[Tue Oct 16 15:51:17 2007] [error] [client 127.0.0.1]   File
"/home/grahamd/scripts/wsgi/commands.py", line 4, in application
[Tue Oct 16 15:51:17 2007] [error] [client 127.0.0.1]     output =
getoutput('uptime')
[Tue Oct 16 15:51:17 2007] [error] [client 127.0.0.1]   File
"commands.py", line 44, in getoutput
[Tue Oct 16 15:51:17 2007] [error] [client 127.0.0.1]     return
getstatusoutput(cmd)[1]
[Tue Oct 16 15:51:17 2007] [error] [client 127.0.0.1]   File
"commands.py", line 55, in getstatusoutput
[Tue Oct 16 15:51:17 2007] [error] [client 127.0.0.1]     sts = pipe.close()
[Tue Oct 16 15:51:17 2007] [error] [client 127.0.0.1] IOError: [Errno
10] No child processes

The reason being that underlying system pclose() function is not able to
get the return status of the sub process as something else appears to have
already consumed the status.

The culprit may centre around how mod_wsgi in daemon mode uses sigwait() to
determine when the daemon process should shutdown, although initial
requests don't show this as being the case. Other possibilities are the way
that in daemon mode signals are blocked from being received by worker
threads, but again, initial tests don't show this as the cause. All up, not
sure at all what is the actual cause and why it would only affect some
operating systems and not others.

Only workaround at this time is to use popen() direct rather than through
wrappers and ignore this error message from close() call on pipe. For example:

def getstatusoutput(cmd):
   """Return (status, output) of executing cmd in a shell."""
   import os
   pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')
   text = pipe.read()
   try:
       sts = None
       sts = pipe.close()
   except:
       pass
   if sts is None: sts = 0
   if text[-1:] == '\n': text = text[:-1]
   return sts, text

Original issue reported on code.google.com by Graham.Dumpleton@gmail.com on 21 Oct 2007 at 1:43

GoogleCodeExporter commented 8 years ago
Fixed in revision 617 of 1.X trunk.

Original comment by Graham.Dumpleton@gmail.com on 26 Oct 2007 at 6:05

GoogleCodeExporter commented 8 years ago

Original comment by Graham.Dumpleton@gmail.com on 30 Oct 2007 at 2:08