Hi Graham, Thanks for noticing it, the webserver has more than 100 python web apps deployed automatically by a script so I actually never noticed they had only ServerAlias (they have like 6-7 ServerAliases each vhost, so I just never noticed ServerNames wasn't in the bunch). Curiously it looks the problem was solved just by upgrading mod_wsgi, so I don't know if that was actually the solution or not. So far it never happened again. In case the websites start again using the wrong virtual-env I'll try to set the ServerName for each of them and see if that was the reason.
Thanks for checking this! Alessandro On Wed, Jan 13, 2016 at 2:46 AM, Graham Dumpleton < [email protected]> wrote: > 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 > WSGIDaemonProcess 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 > WSGIRestrictProcess 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 > WSGIDaemonProcess 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 > WSGIRestrictProcess 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]. > 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. > > > -- > 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. > -- 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.
