Passenger/django problem, something changed recently

I have a that’s been working for years, and suddenly it fails. I have a custom python installation, but the .profile points to the right place, and the whole thing has not been altered in a very long time. Until today. Now everything is broken. It now insists on using /usr/bin/python no matter what, which causes all sorts of issues, and when I try to os.execl() over to my own python, it gives a server 500 error on the web, but works fine when I run on its own. That means it’s the thing that’s calling /usr/local/dh/passenger/lib/phusion_passenger/wsgi/ itself, or that script itself (though the script claims to have not changed in several months).


export HOME=/home/XXX export PYTHONPATH=$HOME/local/lib/python2.6:$HOME/local/lib/python2.6/site-packages:$HOME/local/python/lib:$HOME/$HOME/$HOME/$PYTHONPATH export DJANGO_SETTINGS_MODULE=XXX.settings export PATH=$HOME/local/bin:$HOME/local/python/lib/django/bin:~/dist/bin:$PATH export PYTHON_EGG_CACHE=$HOME/local/python/.python-eggs export PERL5LIB=~/dist/bin:$PERL5LIB

import sys, os home='/home/XXX' sys.path.append(os.getcwd()) sys.path.insert(1,home+'/local/lib/python2.6') sys.path.insert(1,home+'/local/lib/python2.6/site-packages') sys.path.insert(1,home+'/local/python/lib') sys.path.insert(1,home+'/') sys.path.insert(1,home+'/') sys.path.insert(1,home+'/') import re #print("sys.argv="+" ".join(sys.argv)) if not re.match( "2.6.5", sys.version ): os.execlp(home+"/local/bin/python2.6", "python2.6", *sys.argv) os.environ['DJANGO_SETTINGS_MODULE'] = "XXX.settings" import django.core.handlers.wsgi application = django.core.handlers.wsgi.WSGIHandler()

Again, this worked just hunky-dory at very latest last Friday night at midnight, probably more recently. The passenger file is syntax-error-free and properly exec’s to the proper python. The only thing I can think is that they suddenly decided to run as root rather than the local user. But if they changed that without telling anyone, WTF??? That would break anyone with a custom install, and not due to any ridiculous assumptions on the part of the custom installer.

I’m now pulling my hair out seeing if I can make it all run under FCGI instead, now that I can’t find a way out of this myself…

My apologies for the late response. But I too have been struggling with the WSGI passenger engine with Django. In my case I have a much different situation where Django can’t seem to find some of my modules for some reason.

I think you might be able to get your code working by moving your .profile environment settings to a .bash_profile file. This worked for me. Then simply run the “source .bash_profile” command and finally make sure you do a “pkill python”.

Kind Regards,

i’m deploying a flask app and running into the same problem. root is not allowed to run my custom python install and this is leading to the timeouts + 500 errors.

anyone find a workaround yet? did you switch over to fastCGI?

here’s a little script that i used to check that, yes, root is running the process:

[code]import sys, os

virtualenv_root = '/home/username/env’
INTERP = os.path.join(virtualenv_root, ‘bin’, ‘python2.7’)

os.execlp(INTERP, INTERP, *sys.argv)


def application(environ, start_response):
start_response(‘200 OK’, [(‘Content-type’, ‘text/plain’)])
return ‘\n’.join((

[/code]OK. My little workaround is as follows:

  1. I rewrote the few parts of my app that required Python2.7 and tested it locally with Python2.6

  2. I made a local virtualenv using the system-wide Python and installed all the modules I needed into it.

[code]$ virtualenv -p /usr/bin/python .

  1. I added the path to that virtualenv site-packages using sys.path.append. Here’s my script
import sys

from myapp import app as application