On 12/03/2015, at 1:28 PM, Jason Garber <[email protected]> wrote:
> Hi Graham,
>
> I've been starting to work with background processes as a replacement for
> clunky cron-jobs in a major application. Here is what I mean:
>
> WSGIDaemonProcess Async-ShockBox-60011 processes=1 threads=1
> python-path=/home/jason/DevLevel.2/AMSTMT/Python
> display-name=Async-ShockBox-60011
>
> WSGIImportScript /home/jason/DevLevel.2/AMSTMT/Async/ShockBox.py
> process-group=Async-ShockBox-60011 application-group=%{GLOBAL}
>
> This works great:
> 1. the script runs as expected
> 2. if I kill it as root with kill -9 then it is restarted automatically
>
> I have some questions...
>
> 1. Is there any way to select what error log the output goes to. Currently
> it is going to the global apache error log.
Only thing I can think of is to create a fake VirtualHost and set ErrorLog for
it and have the WSGIDaemonProcess directive in it.
<VirtualHost 127.0.0.255:*>
ErrorLog /some/path/error.log
WSGIDaemonProcess Async-ShockBox-60011 processes=1 threads=1
python-path=/home/jason/DevLevel.2/AMSTMT/Python
display-name=Async-ShockBox-60011
WSGIImportScript /home/jason/DevLevel.2/AMSTMT/Async/ShockBox.py
process-group=Async-ShockBox-60011 application-group=%{GLOBAL}
</VirtualHost>
I have thought about an option to WSGIDaemonProcess to override the error log
before, but isn't so simple.
BTW, thanks for asking this question. Will have to allow an error log to be
specified with this trick for service scripts in mod_wsgi-express.
> 2. Is there any way, short of `kill -9` or restarting apache, to restart the
> daemon process that is being used by WSGIImportScript?
The TERM and HUP signals should work as well and will attempt to properly
shutdown the process.
Very recent versions of mod_wsgi should be a lot smarter about handling signals
received if from this service process you fork a new process to do actual work
which you wait on. There was a bug before where if sent a signal to one of the
forked processes that it would actually shutdown the parent mod_wsgi daemon
process because of the loopback UNIX pipe used to tell process to shutdown due
to a signal.
For a forked process, you can register your own signal handlers, but again for
that to work properly, need a very recent mod_wsgi version.
> 3. Is there any way, within a daemon process itself, to restart itself? I
> tried sys.exit() but got this:
>
> mod_wsgi (pid=25983): SystemExit exception raised by WSGI script
> '/home/jason/DevLevel.2/AMSTMT/Async/ShockBox.py' ignored.
Send a SIGINT or SIGTERM to itself should work.
Worst case, us os._exit(). That will do an immediate exit of process and not
try and shutdown Python interpreter, run atexit callbacks etc.
Am curious to hear more about what you are doing and whether this was inspired
by the recent long discussion about WebFaction where I showed how to use a
daemon process to run a multiprocessing module queue manager to accept requests
from WSGI application to do jobs in forked sub processes with timeouts on
processes.
There are all sorts of tricks for using daemon processes don't think anyone
would realise. Want to make my PyCon AU talk this year about it.
For example, did you know that you could fork/exec a redis or memcached inside
of a daemon process and have Apache manage it?
Did you know you could run in a daemon process a mod_wsgi-express against a
different Python version (ie., Python 3 rather than 2) and then setup proxies
from Apache to it for a site name of sub URLs and so have Apache manage
everything, with both Python 2 and Python 3 parts.
:-)
Graham
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.
