mod_wsgi loading python script from wrong Pyramid app directory
Question: I have two apps with nearly identical code base (same functionality, just
different branding) that I am trying to do virtual hosting with using mod_wsgi
and apache.

the virtual host settings for both apps (in two separate files) are identical
(with the exception of paths of course)

    
    
    WSGIPythonHome /home/ubuntu/BASELINE
    
    <VirtualHost *:80>
        ServerName appA.com
        ServerAlias www.appA.com
        ServerAdmin admin@appA.com
        DocumentRoot /home/ubuntu/appA_virtualenv/appA-server/appA
        ErrorLog /home/ubuntu/appA_virtualenv/appA-server/error.log
        CustomLog /home/ubuntu/appA_virtualenv/appA-server/access.log combined
    
        Alias /static/ /home/ubuntu/appA_virtualenv/appA-server/appA/appA/static/
    
        WSGIApplicationGroup %{GLOBAL}
        WSGIPassAuthorization On
        WSGIDaemonProcess appA user=www-data group=www-data \
            python-path=/home/ubuntu/appA_virtualenv/lib/python2.7/site-packages/ \
            home=/home/ubuntu/appA_virtualenv/appA-server/appA/
        WSGIProcessGroup appA
        WSGIScriptAlias / /home/ubuntu/appA_virtualenv/appA-server/appA.wsgi
    
        <Directory /home/ubuntu/appA_virtualenv/appA-server>
            WSGIProcessGroup appA
            Order allow,deny
            Allow from all
        </Directory>
    </VirtualHost>
    

.

    
    
    <VirtualHost *:80>
        ServerName appB.com
        ServerAlias www.appB.com
        ServerAdmin admin@appB.com
        DocumentRoot /home/ubuntu/appB_virtualenv/server/appB
        ErrorLog /home/ubuntu/appB_virtualenv/server/error.log
        CustomLog /home/ubuntu/appB_virtualenv/server/access.log combined
    
        Alias /static/ /home/ubuntu/appB_virtualenv/server/appB/appB/static/
    
        WSGIApplicationGroup %{GLOBAL}
        WSGIPassAuthorization On
        WSGIDaemonProcess appB user=www-data group=www-data \
            python-path=/home/ubuntu/appB_virtualenv/lib/python2.7/site-packages/ \
            home=/home/ubuntu/appB_virtualenv/server/appB/
        WSGIProcessGroup appB
        WSGIScriptAlias / /home/ubuntu/appB_virtualenv/server/appB.wsgi
    
        <Directory /home/ubuntu/appB_virtualenv/server>
            WSGIProcessGroup appB
            Order allow,deny
            Allow from all
        </Directory>
    </VirtualHost>
    

Contents of `appA.wsgi`

    
    
    import os
    os.environ['PYTHON_EGG_CACHE'] = '/home/ubuntu/appA_virtualenv/appA-server/python-eggs'
    
    from pyramid.paster import get_app, setup_logging
    ini_path = '/home/ubuntu/appA_virtualenv/appA-server/appA/development.ini'
    setup_logging(ini_path)
    application = get_app(ini_path, 'main')
    

Contents of `appB.wsgi`

    
    
    import os
    os.environ['PYTHON_EGG_CACHE'] = '/home/ubuntu/appB_virtualenv/server/python-eggs'
    
    from pyramid.paster import get_app, setup_logging
    ini_path = '/home/ubuntu/appB_virtualenv/server/appB/development.ini'
    setup_logging(ini_path)
    application = get_app(ini_path, 'main')
    

I enabled both sites in apache and realize that when accessing appA, the
python scripts in appB's directory is loaded instead. I confirmed this by
adding a `print` statement in the `__init__.py` of both apps and the text for
appB is printed even when I try to access appA.

I then disabled appB by `$ sudo a2dissite appB`. appB.com fails to load, but
appA.com is still loading appB's codes...

I added the following to **appB** `__init__.py` (Note: NOT **appA**)

    
    
    print sys.path[0]
    print os.getcwd()
    

the outputs are

    
    
    /home/ubuntu/appA_virtualenv/lib/python2.7/site-packages/pip-1.2.1-py2.7.egg
    /home/ubuntu/appA_virtualenv/appA-server/appA
    

which is beyond my comprehension because the output point correctly to appA's
directory, yet the `print` are added to appB's `__init__.py` which is located
in `/home/ubuntu/appB_virtualenv/server/appB/appB/__init__.py`

Also, I have already disabled appB and the apache settings no longer refer to
appB's directory anywhere anymore, so why is appA still loading appB's
scripts?!

what am I doing wrong? What settings do I need to change to get appA to load
the scripts in its own directory? Thanks

* * *

Additional checks as suggested by Graham

[Embedded or Daemon
Mode](http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Embedded_Or_Daemon_Mode)

  * Daemon mode: `mod_wsgi.process_group = 'appA'`

[Sub Interpreter Being
Used](http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Sub_Interpreter_Being_Used)

  * Main Interpreter: `mod_wsgi.application_group = ''`

[Request
Environment](http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Displaying_Request_Environment)

  * `PATH_TRANSLATED: '/home/ubuntu/appA_virtualenv/appA-server/appA.wsgi/'`
  * `SERVER_NAME: 'appA.com'`
  * `SCRIPT_FILENAME: '/home/ubuntu/appA_virtualenv/appA-server/appA.wsgi'`
  * `mod_wsgi.application_group: ''`
  * `mod_wsgi.process_group: 'appA'`
  * `mod_wsgi.version: (3, 4)`


Answer: Nothing looks an issue on first glance.

Use:

  * <http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Embedded_Or_Daemon_Mode>
  * <http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Sub_Interpreter_Being_Used>

to confirm what process and application group they are each executing in.

Use:

  * <http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Displaying_Request_Environment>

to see what SERVER_NAME is set to for each in requests.

Edit your question with the results.

* * *

UPDATE 1

Where there are two VirtualHost's in the Apache configuration, one cause of
requests always ending up at the first VirtualHost and never reaching the
second is because NameVirtualHost directive isn't being specified for the port
the VirtualHost's are listening on. Normally on Linux this isn't a problem
though for port 80 as it would be on by default.

The other reason it can occur is because the host name used in the URL doesn't
actually match either the ServerName or ServerAlias in the desired
VirtualHost. When this happens Apache will fallback to directing the URL to
the first VirtualHost it found when the Apache configuration file was read. To
catch when this is occurring, it is generally a good idea to declare a default
VirtualHost which is read first and which denies all access. At least this way
a request will not end up at the wrong VirtualHost and will be blocked.

For details of this issue with it falling back to the first read VirtualHost,
see discussion in:

  * <http://blog.dscpl.com.au/2012/10/requests-running-in-wrong-django.html>

Try defining the default VirtualHost and see whether this issue of it falling
back to the first VirtualHost is the issue. Then you can workout what is the
issue with the Apache configuration which is causing that to occur.

