2008/11/17 rtl <[EMAIL PROTECTED]>:
>
> After running for approximately 5 days a Django app running under
> mod_wsgi fails with the following error:
>
> ExtractionError: Can't extract file(s) to egg cache
> The following error occurred while trying to extract file(s) to the
> Python egg cache:
> [Errno 13] Permission denied: 'MySQL_python-1.2.2-py2.5-solaris-2.11-
> i86pc.egg-tmp'
> The Python egg cache directory is currently set to: \xae\xc7\xfaD
> \xd8\xc8\x15\b
>
> This happens on two different Joyent virtual boxes at different times
> of the day, depending on when Apache was last restarted. The corrupt
> directory name is different each time.
>
> I've tried it with a global egg setting (WSGIPythonEggs) and daemon
> process specific setting as follows:
>
> WSGIDaemonProcess app user=www group=www processes=10 threads=1
> display-name=%{GROUP} python-path=/opt/app/src python-eggs=/tmp/egg/
> app/ inactivity-timeout=60
> WSGIApplicationGroup %{GLOBAL}
> WSGIProcessGroup app
>
> Apache serves two different Django apps in single-threaded daemon mode
> and a php fastcgi app.
>
> The setup is:
> 1. Apache 2.2.9 (compiled from the coolstack src)
> Server MPM: Worker
> threaded: yes (fixed thread count)
> forked: yes (variable process count)
> 2. mod_wsgi 2.1
> 3. Python 2.5.2 compiled in shared mode
>
> All comments/suggestions on this strange one gratefully accepted!
What WSGIPythonEggs and python-eggs do is the equivalent of:
os.environ['PYTHON_EGG_CACHE'] = '/some/path'
It just does it at C code level when process is first started.
For the value to change then Python code as part of application or
some third party package would have to be overriding that value by
setting os.environ at some point. This would have to be happening
though between time process started and first request handled that
caused Django instance to be loaded and consequently the MySQL client
library as well.
The only other option is that memory corruption is occurring somehow,
which I would have expected you would see manifesting in other ways as
well rather than specifically this.
What I would suggest is making when Django is loaded more predictable,
by preloading it into daemon process by specifying at global
configuration scope.
WSGIImportScript /some/path/to/your/django/wsgi/script.wsgi \
process-group=app application-group=%{GLOBAL}
Even if WSGIDaemonProcess is inside of VirtualHost, this has to be
outside of VirtualHost which is a bit silly. Is a ticket for that
though at 'http://code.google.com/p/modwsgi/issues/detail?id=110'.
If that doesn't help, then set PYTHON_EGG_CACHE yourself from the the
WSGI script file before importing anything in case there is some sort
of corruption happening in the Apache parent process with the saved
configuration used to set the variable in child process.
You might also consider upgrading to mod_wsgi 2.3, not that know of
any specific problems that were fixed and which would cause this.
I'll also do some checking and thinking in case I find something in
code which might be an issue.
Graham
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
