On 25/04/2014, at 1:36 AM, [email protected] wrote:
> We're trying to run multiple apps in a single apache 2.2.14 server, with the
> latest mod_wsgi 3.4.
>
> Each app seems to work fine on it's own, but when running them both
> seperately, we are having problems where some packages are leaking from one
> apps virtual env into the other.
>
>
> We have a baseline environment we set via WSGIPythonHome
> WSGIPythonHome /wsgi/shared/baseline_env/
>
> We configure the apps like this:
>
> # App A
> # The same process should host /root/foo/A, /root/bar/A, etc.
> WSGIDaemonProcess appA user=www-data group=www-data \
> python-path=/wsgi/shared/A/env/lib/python2.6/site-packages/ \
> display-name=%{GROUP}
> WSGIScriptAliasMatch ^/root/[^/]+/A /wsgi/shared/A/A.wsgi
> <Location /root/*/A>
> WSGIProcessGroup appA
> WSGIApplicationGroup %{GLOBAL}
> </Location>
>
> # App B
> # The same process should host /root/foo/B, /root/bar/B, etc.
> WSGIDaemonProcess appB user=www-data group=www-data \
> python-path=/wsgi/shared/BA/env/lib/python2.6/site-packages/ \
> display-name=%{GROUP}
> WSGIScriptAliasMatch ^/root/[^/]+/B /wsgi/shared/B/B.wsgi
> <Location /root/*/B>
> WSGIProcessGroup appB
> WSGIApplicationGroup %{GLOBAL}
> </Location>
Since you are using mod_wsgi 3.4, you can get rid of WSGIPythonHome and use
python-home option to WSGIDaemonProcess instead:
# App A
# The same process should host /root/foo/A, /root/bar/A, etc.
WSGIDaemonProcess appA user=www-data group=www-data \
python-home=/wsgi/shared/A/env display-name=%{GROUP}
WSGIScriptAliasMatch ^/root/[^/]+/A /wsgi/shared/A/A.wsgi \
process-group=appA application-group=%{GLOBAL}
# App B
# The same process should host /root/foo/B, /root/bar/B, etc.
WSGIDaemonProcess appB user=www-data group=www-data \
python-home=/wsgi/shared/BA/env display-name=%{GROUP}
WSGIScriptAliasMatch ^/root/[^/]+/B /wsgi/shared/B/B.wsgi \
process-group=appB application-group=%{GLOBAL}
This avoids needing to each down into the Python virtual environment.
Have also used process-group and application-group to avoid separate Location
for overriding.
I am concerned though as to why you are using WSGIScriptAliasMatch in the first
place.
That should only ever be used as a last resort.
As far as I can tell it should be equivalent to:
# App A
# The same process should host /root/foo/A, /root/bar/A, etc.
WSGIDaemonProcess appA user=www-data group=www-data \
python-home=/wsgi/shared/A/env display-name=%{GROUP}
WSGIScriptAlias /root/A /wsgi/shared/A/A.wsgi \
process-group=appA application-group=%{GLOBAL}
# App B
# The same process should host /root/foo/B, /root/bar/B, etc.
WSGIDaemonProcess appB user=www-data group=www-data \
python-home=/wsgi/shared/BA/env display-name=%{GROUP}
WSGIScriptAlias /root/B /wsgi/shared/B/B.wsgi \
process-group=appB application-group=%{GLOBAL}
Why are you using WSGIScriptAliasMatch?
Do you really want the sites URL prefixed with '/root'?
> In each wsgi file we are also using the suggested section to re-order the
> packages:
>
> VENV_PATH = '/wsgi/shared/A/env/lib/python2.6/site-packages'
> # Remember original sys.path.
> prev_sys_path = list(path)
>
> # Add each new site-packages directory.
> addsitedir(VENV_PATH)
>
> # Reorder sys.path so new directories at the front.
> new_sys_path = []
> for item in list(path):
> if item not in prev_sys_path:
> new_sys_path.append(item)
> path.remove(item)
> path[:0] = new_sys_path
You should not have needed this in the WSGI script file as the python-path
option was doing that for you anyway.
So should not be needed for either python-path or python-home.
> The last line of my wsgi file does this:
> from pyramid.paster import get_app, setup_logging
>
> setup_logging(INI_PATH)
> application = get_app(INI_PATH, INI_SECTION)
>
> and I get intermittent error logs where sometimes app A uses B's version of
> pyramid and errors out, and sometimes vice versa.
>
>
> I wrote some logging code to verify what was happening with the path:
>
> with open("/tmp/path_log.txt", "w") as f:
> f.write("Spinning up B app...\n")
> f.write("Original path:\n")
> for e in prev_sys_path:
> f.write(e + "\n")
>
> f.write("Current:\n")
> for e in path:
> f.write(e + "\n")
>
> E.g. This output shows B getting a correctly ordered path with it's instance
> of pyramid above A's
> https://gist.github.com/anonymous/7ff0841a32bfdfe50818
> and yet that was one of the times I got an error log saying it was trying to
> use A's version of pyramid.
You would have been better off verifying that things were running in the right
mode and interpreter context.
http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Embedded_Or_Daemon_Mode
http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Sub_Interpreter_Being_Used
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.
