To be dealt with after change freeze. Two pieces to this puzzle:
This is unnecessary and could potentially break future code that wants to read docstrings. It's a better idea to set this to {{{WSGIPythonOptimize 1}}}. This change should have nearly no impact on us.
{{{
cd /usr/lib/python2.4/site-packages/fas patch -p2 < ~/fas-email.patch rm user.pyc user.pyo /etc/init.d/httpd graceful }}}
This restarted the fas processes but the new server threads were unable to find the user.py file. Instead, they kept looking for user.pyo and only user.pyo. Documented behaviour for the python interpreter would be to fallback on the .py file and try to use that both to startup and to create a user.pyo file. Running: {{{ sudo python -O -c 'import compileall; compileall.compile_dir(".", '2', "/", 1) }}}
compiled a pyo file from user.py and then we were able to continue. WSGIPythonOptimize might be the cause of this as well. I'm leaning against that, though, as we're running WSGIPythonOptimize 2 on fas1.stg and that seems to work.
Until we fix or figure out what's happening, remember that any hotfixes to the fas servers need to regenerate the pyo files with the compileall line.
I switched all of our usage of WSGIPythonOptimize from 2 to 1.
configs/web/applications/bodhi-masher.conf.erb | 2 +- configs/web/applications/bodhi.conf.erb | 2 +- configs/web/applications/elections.conf | 2 +- configs/web/applications/trac-wsgi.conf | 2 +- modules/fas/files/accounts.conf | 2 +- .../templates/fedoracommunity.conf.erb | 2 +-
I tested on fas1. The good news is pyo files are no longer necessary. The bad news is that I was unable to replicate the problem so we don't know quite what fixed it.
Login to comment on this ticket.