How do you fix a Trac installation that begins giv

Question

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?

Answer 1

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...

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.