2009/2/18 Tom Davis <[email protected]>: > > Graham, > > I did as you recommended and got the following output in error_log: > > subprocess pid 30467 > hello grumpy > > However, following that were various warnings about signal > registration being ignored, as it attempted to do the rest of the > function (I tacked your code onto the beginning): > > [Tue Feb 17 21:48:32 2009] [warn] mod_wsgi (pid=30467): Callback > registration for signal 15 ignored.
It is a bit antisocial of library type component modules to think they control the process execution environment and register signals. :-( Was it only for signal 15? Is that SIGTERM on your operating system? Are you using embedded mode or daemon mode? There are currently issues with creating sub processes from daemon mode processes where sub processes need to handle signals. > So, it would appear that the child is being spawned/run, but only in > the simplest sense. The mod_wsgi rules seem to make it ignore > signals. If I add back WSGIRestrictSignal Off, the warnings go away, > but the function still doesn't *do* anything. The purpose of the > target function is to make some http requests (via Twisted) then parse > those requests, which involves running the Twisted reactor (the entire > reason I am spawning a new process; the reactor cannot run within a > mod_wsgi thread). It seems this is causing a problem for some reason. > Obviously the target function is being run, as evidenced by the output > in error_log, but Twisted is having trouble with signaling within it > (at least, that is my only guess). As I said, this only seems to be > affected when running w/ mod_wsgi; any other time the function works > fine. Any particular reason you are using Twisted just to do HTTP requests rather than simpler Python HTTP client modules. Anyway, let me have a think about it for a while. Graham > On Feb 17, 10:03 pm, Graham Dumpleton <[email protected]> > wrote: >> 2009/2/18 Tom Davis <[email protected]>: >> >> >> >> >> >> > I am trying to use multiprocessing within a modwsgi app and am having >> > an issue. At first I was getting errors regarding permissions to use >> > stdout, etc. I fixed these by setting WSGIRestrictStdout, >> > WSGIRestrictStdin, and WSGIRestrictSignal to Off in my conf file. Now >> > I get no errors, but the process doesn't actually run. My usage is >> > quite simple: on a page request, I try something along the lines of: >> >> > p = multiprocessing.Process(target=fn, args...) >> > p.start() >> > p.join() >> >> > The target doesn't output anything, but if run properly it should add >> > some records to the database. I tested that it works normally by >> > running the app under the django development server, which doesn't >> > seem to have an issue with multiprocessing. Has anyone encountered >> > this before? >> >> What does the target function do? >> >> Try following WSGI script file. Note that for this script you will >> need to look in main Apache error log for output, even if WSGI script >> defined in VirtualHost context and that VirtualHost has its own error >> log. This is because am reseting stdin/stdout/stderr back to original >> values. Take out the WSGIRestrictStdin, WSGIRestrictStdout and >> WSGIRestrictSignal directives you already added. >> >> from multiprocessing import Process >> >> import sys, os >> >> sys.stdin = sys.__stdin__ >> sys.stdout = sys.__stdout__ >> sys.stderr = sys.__stderr__ >> >> def f(name): >> sys.stderr.write('subprocess pid %d\n' % os.getpid()) >> sys.stderr.write('hello %s\n' % name) >> sys.stderr.flush() >> >> def application(environ, start_response): >> status = '200 OK' >> output = 'Hello World!' >> >> sys.stderr.write('parent pid %d\n' % os.getpid()) >> sys.stderr.flush() >> >> p = Process(target=f, args=('grumpy',)) >> p.start() >> p.join() >> >> response_headers = [('Content-type', 'text/plain'), >> ('Content-Length', str(len(output)))] >> start_response(status, response_headers) >> >> return [output] > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
