unable to browse source via trac

[darran]

Traceback (most recent call last):
  File "/usr/lib/python2.3/site-packages/trac/core.py", line 531, in cgi_start
    real_cgi_start()
  File "/usr/lib/python2.3/site-packages/trac/core.py", line 526, in real_cgi_start
    dispatch_request(path_info, args, req, env)
  File "/usr/lib/python2.3/site-packages/trac/core.py", line 439, in dispatch_request
    module = module_factory(args, env, database, req)
  File "/usr/lib/python2.3/site-packages/trac/core.py", line 175, in module_factory
    pool, rep, fs_ptr = open_svn_repos(repos_dir)
  File "/usr/lib/python2.3/site-packages/trac/core.py", line 458, in open_svn_repos
    rep = repos.svn_repos_open(repos_dir, pool)
SubversionException: ("Berkeley DB error while opening 'nodes' table for filesystem /home/svn/ga/db:\nCannot allocate memory", 160029)

[ole]

The ANU Subversion server went down 30th April just before 7pm. Stephen Roberts has submitted a helpdesk request.

[steve]

Somehow the ga repository had some locked files. Odds are there was still a lock file on something in the repos that wasn't suppose to be there. The apache error logs alerted to the 'nodes' table in the DB.

In the end the following command was ran:

svnadmin recover /home/svn/ga/

and then

chown www-data:www-data -R /home/svn/ga/

The first command changed some of the repos files ownership (in the /home/svn/ga/db/ folder) to root.

[ole]

The problem reappeared today. Steve rebooted datamining which regained access to the datamining websit but the repository and browsing source via TRAC is still unavailable.

[steve]

We had to delete the old repository and create it a new. THe version was from yesterday (2/5/07), so if you made changes and committed changes yesterday, then they will be lost on the repository.

Now we don't know if the repository was corrupted on our end or if it has been up loaded from someone's checked out version.

THe recommendation is to checkout a new clean version of the repository and work from there. (Iniitally I would suggest keeping your old version and copying over any files not committed to the repository (large data files etc).

Fingers crossed that the corruption doesn't show up again.

[darran]

Hi Steve.

For our company SVN, we opted for the "flat file" rather than the Berkeley database. Did you make a conscious decision in this regard?

Cheers, Darran.

[steve]

Well, its down again.

At least the apache server is working again and you can get onto TRAC, but the repository is broken again. We are thinking of creating a new repository and see if that one can survive the night.

We are unsure if there is some strange interaction between backups occuring on the machine, or a svn problem, or a disk problem etc.

We will keep plugging away.

As regard Darran's question, I think we use the Berkeley database. I don't think we had any strong feelings either way.

[anonymous]

Fixed by Matt Oliver by reinstalling Subversion using flat files and also reinstalling TRAC. Well done Matt!