Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I had a fairly simple question. When mod_wsgi is run in Daemon mode, and you enable the WSGIDaemonProcess and WSGIProcessGroup directives on a per virtual host basis, are these picked up by other virtual hosts as well?

For example, if I have:

<VirtualHost *:80>
WSGIDaemonProcess example.com processes=2 threads=15 display-name=%{GROUP}
WSGIProcessGroup example.com
</VirtualHost>

<VirtualHost *:443>
WSGIProcessGroup example.com
</VirtualHost>

Will the second 443 virtual host use the existing "example.com" process group defined in the first 80 virtual host? Or do I have to redefine a separate process group within the second 443 virtual host?

share|improve this question

1 Answer 1

up vote 4 down vote accepted

Quoting the documentation at:

http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess

behaviour is:

If the WSGIDaemonProcess directive is specified outside of all virtual host containers, any WSGI application can be delegated to be run within that daemon process group. If the WSGIDaemonProcess directive is specified within a virtual host container, only WSGI applications associated with virtual hosts with the same server name as that virtual host can be delegated to that set of daemon processes.

So, you can reach across to daemon process definition in prior virtual host so long as same server name.

You also need to be aware of what is said in:

http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIApplicationGroup

whereby for default for WSGIApplicationGroup (ie., if not specified) is:

%{RESOURCE}

The application group name will be set to the server hostname and port as for the %{SERVER} variable, to which the value of WSGI environment variable SCRIPT_NAME is appended separated by the file separator character.

For example, if the virtual host www.example.com was handling requests on port 8080 and the URL-path which mapped to the WSGI application was http://www.example.com/wsgi-scripts/foo, then the application group name would be set to www.example.com:8080|/wsgi-scripts/foo.

The effect of using the %{RESOURCE} variable expansion is for each application on any server to be isolated from all others by being mapped to its own Python sub interpreter.

So, normally if you had separate WSGIScriptAlias for same mount point in the two virtual hosts for different ports, the two application instances would still be separated by running in different sub interpreters.

There is an exception to this rule though for the port 80/443 case whereby the port isn't actually included in the application group name. Thus in that case, applications mounted at same mount point would run in same sub interpreter.

This exception probably isn't explained as clearly as it could, but is covered by the definition:

%{SERVER}

The application group name will be set to the server hostname. If the request arrived over a non standard HTTP/HTTPS port, the port number will be added as a suffix to the group name separated by a colon.

For example, if the virtual host www.example.com is handling requests on the standard HTTP port (80) and HTTPS port (443), a request arriving on either port would see the application group name being set to www.example.com. If instead the virtual host was handling requests on port 8080, then the application group name would be set to www.example.com:8080.

that expansion of that being used as part of the default expansion above.

share|improve this answer
    
Thanks Graham - excellent answer, as always! –  shreddd Jul 23 '11 at 3:18

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.