Opened 17 years ago

Closed 17 years ago

#146 closed defect (fixed)

unable to browse source via trac

Reported by: darran Owned by: steve
Priority: highest Milestone:
Component: Management and planning Version: 1.0
Severity: critical Keywords:
Cc: darran@…


Traceback (most recent call last):
  File "/usr/lib/python2.3/site-packages/trac/", line 531, in cgi_start
  File "/usr/lib/python2.3/site-packages/trac/", line 526, in real_cgi_start
    dispatch_request(path_info, args, req, env)
  File "/usr/lib/python2.3/site-packages/trac/", line 439, in dispatch_request
    module = module_factory(args, env, database, req)
  File "/usr/lib/python2.3/site-packages/trac/", line 175, in module_factory
    pool, rep, fs_ptr = open_svn_repos(repos_dir)
  File "/usr/lib/python2.3/site-packages/trac/", 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)

Change History (8)

comment:1 Changed 17 years ago by ole

  • Owner changed from ole to steve

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

comment:2 Changed 17 years ago by ole

  • Cc darran@… added

comment:3 Changed 17 years ago by steve

  • Resolution set to fixed
  • Status changed from new to closed

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.

comment:4 Changed 17 years ago by ole

  • Component changed from Appearance and visualisation to Management
  • Priority changed from normal to highest
  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:5 Changed 17 years ago by steve

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

comment:6 Changed 17 years ago by 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.

comment:7 Changed 17 years ago by steve

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:8 Changed 17 years ago by anonymous

  • Resolution set to fixed
  • Status changed from reopened to closed

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

Note: See TracTickets for help on using tickets.