Delegation To Daemon Process
By default any WSGI application will run in what is called embedded mode. That is, the application will be hosted within the Apache worker processes used to handle normal static file requests.
When embedded mode is used, whenever you make changes to your WSGI application code you would generally have to restart the whole Apache web server in order for changes to be picked up. This can be inconvenient, especially if the web server is a shared resource hosting other web applications at the same time, or you don’t have root access to be able to restart the server and rely on someone else to restart it.
On UNIX systems when running Apache 2.X, an option which exists with mod_wsgi and that avoids the need to restart the whole Apache web server when code changes are made, is to use what is called daemon mode.
In daemon mode a set of processes is created for hosting a WSGI application, with any requests for that WSGI application automatically being routed to those processes for handling.
When code changes are made and it is desired that the daemon processes for the WSGI application be restarted, all that is required is to mark the WSGI application script file as modified by using the ‘touch’ command.
To make use of daemon mode for WSGI applications hosted within a specific site, the WSGIDaemonProcess and WSGIProcessGroup directives would need to be defined. For example, to setup a daemon process group containing two multithreaded process one could use:
WSGIDaemonProcess example.com processes=2 threads=15 WSGIProcessGroup example.com
A complete virtual host configuration for this type of setup would therefore be something like:
<VirtualHost *:80> ServerName www.example.com ServerAlias example.com ServerAdmin webmaster@example.com DocumentRoot /usr/local/www/documents Alias /robots.txt /usr/local/www/documents/robots.txt Alias /favicon.ico /usr/local/www/documents/favicon.ico Alias /media/ /usr/local/www/documents/media/ <Directory /usr/local/www/documents> Order allow,deny Allow from all </Directory> WSGIDaemonProcess example.com processes=2 threads=15 display-name=%{GROUP} WSGIProcessGroup example.com WSGIScriptAlias / /usr/local/www/wsgi-scripts/myapp.wsgi <Directory /usr/local/www/wsgi-scripts> Order allow,deny Allow from all </Directory> </VirtualHost>
After appropriate changes have been made Apache will need to be restarted. For this example, the URL ‘http://www.example.com/‘ would then be used to access the the WSGI application.
Note that you obviously should substitute the paths and hostname with values appropriate for your system.
As mentioned previously, the daemon processes will be shutdown and restarted automatically if the WSGI application script file is modified.
For the sample application presented in this document the whole application is in that file. For more complicated applications the WSGI application script file will be merely an entry point to an application being imported from other Python modules or packages. In this later case, although no change may be required to the WSGI application script file itself, it can still be touched to trigger restarting of the daemon processes in the event that any code in the separate modules or packages is changed.
Note that only requests for the WSGI application are handled within the context of the daemon processes. Any requests for static files are still handled within the Apache worker processes.