Sorry for the delay on this. Was having problems with Internet at home the last week, so was ignoring a lot of stuff.
One basic problem with your setup is that the VirtualHost definitions aren’t even specifying a ServerName. It is not enough to have just ServerAlias and I am surprised that anything is working at all. If VirtualHost’s are not set up correctly, then everything will end up being handled by the first VirtualHost found in the Apache configuration file. Graham > On 7 Jan 2016, at 10:52 PM, Alessandro Molina <[email protected]> > wrote: > > I'm currently facing an unexpected behaviour when running two different apps > within differente WSGIDaemonProcess. It looks like the venv of one is added > to the other and I have been able to solve the issue only by removing the > second one from apache configuration. > > As I host multiple WSGI apps on same server all of them only run in Daemon > Mode, the global mod_wsgi configuration only has two options: > > WSGILazyInitialization On > WSGIRestrictEmbedded On > > Then each app is configured inside its own virtual host. > App1 uses some C modules and so is configured to use %GLOBAL application > group: > > <VirtualHost *:80> > ServerAlias app1.domain.com <http://app1.domain.com/> > WSGIDaemonProcess app1.domain.com <http://app1.domain.com/> > display-name=app1_domain_com user=aw252 group=awapps processes=1 threads=5 > maximum-requests=5000 inactivity-timeout=3600 stack-size=524288 > WSGIProcessGroup app1.domain.com <http://app1.domain.com/> > WSGIRestrictProcess app1.domain.com <http://app1.domain.com/> > WSGIScriptAlias /run.wsgi /var/www/252/run.wsgi > WSGIApplicationGroup %{GLOBAL} > </VirtualHost> > > App2 runs fine and so doesn't set any app group: > > <VirtualHost *:80> > ServerAlias app2.domain.com <http://app2.domain.com/> > WSGIDaemonProcess app2.domain.com <http://app2.domain.com/> > display-name=app2_domain_com user=aw551 group= awapps processes=1 threads=5 > maximum-requests=5000 inactivity-timeout=3600 stack-size=524288 > WSGIProcessGroup app2.domain.com <http://app2.domain.com/> > WSGIRestrictProcess app2.domain.com <http://app2.domain.com/> > WSGIScriptAlias /run.wsgi /var/www/551/run.wsgi > </VirtualHost> > > Then the two apps work in separate virtualenvs activated by their own > run.wsgi like this: > > VIRTUAL_ENV = "/var/www/252/penv" > APP_PATH = "/var/www/252/app" > import site > site.addsitedir('%s/lib/python2.7/site-packages' % VIRTUAL_ENV) > site.addsitedir('/var/www/252') > import os, sys > sys.path.append(SITE_PATH) > from app.wsgi_application import init_application > _application = init_application(APP_PATH) > > The run.wsgi for app2 looks the same but has 551 as path: > > VIRTUAL_ENV = "/var/www/551/penv" > SITE_PATH = "/var/www/551/app" > import site > site.addsitedir('%s/lib/python2.7/site-packages' % VIRTUAL_ENV) > site.addsitedir('/var/www/551') > import os, sys > sys.path.append(SITE_PATH) > from app.wsgi_application import init_application > _application = init_application(SITE_PATH) > > The odd part is that if app1 is enabled, then app2 (551) starts with the app1 > virtualenv inside sys.path: > > ['/var/www/252/penv/local/lib/python2.7/site-packages/distribute-0.6.24-py2.7.egg', > ' > '/var/www/252/penv/local/lib/python2.7/site-packages/Babel-2.2.0-py2.7.egg', > '/var/www/551/penv/lib/python2.7/site-packages/FormEncode-1.3.0-py2.7.egg', > '/var/www/551/penv/lib/python2.7/site-packages/nine-0.3.4-py2.7.egg', > '/var/www/551/app'] > > I always though WSGIProcessGroup wins over WSGIApplicationGroup and so two > apps with different process groups could never mess the interpreter > configuration of another app, but it looks like this is not actually true as > app1 is actually touching the sys.path of app2 even though they are in two > different groups. > > Any idea of what I can look to as the cause of this behaviour? > > > -- > 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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/modwsgi > <https://groups.google.com/group/modwsgi>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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 https://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
