We've been using Trac for task/defect tracking and things were going well enough, but this morning it started serving up a 500 error. Looking in the Apache error_log, I get a stack trace that culminates in:
PythonHandler trac.web.modpython_frontend:
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: '/.python-eggs'
The Python egg cache directory is currently set to:
/.python-eggs
Perhaps your account does not have write access to this directory? You can
change the cache directory by setting the PYTHON_EGG_CACHE environment
variable to point to an accessible directory
So I explicitly set PYTHON_EGG_CACHE to /srv/trac/plugin-cache. I restarted Apache. Yet I get the same error (it still says "egg cache directory current set to: \n\n /.python_eggs.")
How should I proceed? Is the simplest thing to do to reinstall Trac? If I go that route, what steps do I need to take to ensure that I don't lose existing data?
That should be fixed in 0.11 according to their bug tracking system.
If that's not the case you should try to pass the environment var to apache, since doing a SetEnv in the configuration file doesn't work. Adding something like
export PYTHON_EGG_CACHE=/tmp/python_eggs
to the script you use to start apache should work.
I ran into the same problem when upgrading from Trac 10.4 to 0.11 earlier this year. Something must have changed for this problem to have just suddenly appeared -- an updated Python or Apache installation?
I don't remember all of the permutations I tried to solve this, but I ended up having to use SetEnv PYTHON_EGG_CACHE /.python-eggs and create /.python-eggs with 777 permissions. This might not be the best solution, but it fixed the problem.
I never investigated what the root cause was. As agnul says, this may have been fixed in a subsequent Trac release.
I have wrestled many a battle with PYTHON_EGG_CACHE and I never figured out the correct way of setting it - apache's envvars, httpd.conf (SetEnv and PythonOption), nothing worked. In the end I just unpacked all python eggs manually, there were only two or three anyway - problem gone. I never understood why on earth people zip up files weighting no more than a few kilobytes in the first place...
I had the same problem. In my case the directory wasn't there so I created and chown'ed it over to the apache user (apache on my centos 4.3 box). Then made sure it had read-write permissions on the directory. You could get by with giving rw rights to the directory if the group that owns the directory contains the apache user. A simple ps aux|grep httpd should show you what account your server is running under if you don't know it. If you have trouble finding the directory remember the -a on the ls command since it is a "hidden" directory.
I found that using the PythonOption directive in the site config did not work, but SetEnv did. The environment variable route will also work though.
