If the Python shared library had changed, you may well need to have done a complete stop and start of Apache. A restart or reload may not have been enough as an Apache restart doesn't actually shutdown the Apache parent process. If on the restart when Apache unloads mod_wsgi.so the Python shared library didn't also unload properly, then when mod_wsgi was reloaded again after rereading configuration, it may have used old Python shared library that was still sticky against the Apache process.
That is about all I can think of as a reason. Graham On 22 May 2012 22:36, Hanne Moa <[email protected]> wrote: > After the system python was updated to 2.6.8 *some* mod_wsgi scripts > failed to import urandom from os. No, not those using virtualenv but > those *not* using virtualenv. > > Traceback (most recent call last): > File "my.wsgi", line 33, in application > from os import urandom as _urandom > ImportError: cannot import name urandom > > The application in "my.wsgi" is: > > def application(environ, start_response): > status = '200 OK' > output = str(sys.path) > > from os import urandom as _urandom > > response_headers = [('Content-type', 'text/plain'), > ('Content-Length', str(len(output)))] > start_response(status, response_headers) > > return [output] > > After barking up several wrong trees in the wrong forests (it worked > from the command lline, it worked if the application was using a > python in a virtualenv, it did not work with the system python and > system libraries) I finally checked the apache conf and discovered > that the *only* difference between the working and non-working > environments was that the _working_ one was: > > WSGIDaemonProcess itworks threads=10 maximum-requests=10 > > while the _non-working_ one was: > > WSGIDaemonProcess noworkee processes=2 maximum-requests=10 > > Changing the latter to the former and hey presto! It worked as if by magic. > > Apache2 had been upgraded and restarted prior to the python upgrade > and several times after. The offending os.py finally seems to be gone > because both threads and processes work now, for both virtual hosts. > > Now, I'm wondering how these two, threads and processes, differ, since > the processes one must still have been pointing to the wrong os.py for > much longer than the threads one. It feels like the only thing I > didn't do to fix this problem was to reboot the server. How can I make > sure after the next upgrade that this problem (lingering old versions) > does not reoccur? > > > HM > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en. > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
