> -----Original Message-----
> From: Peter Howard [mailto:email@example.com]
> Sent: Monday, January 06, 2003 6:38 PM
> To: Brandon Ehle
> Cc: Subversion Dev list
> Subject: RE: Repository "hung"
> > -----Original Message-----
> > From: Peter Howard [mailto:firstname.lastname@example.org]
> > Sent: Thursday, December 19, 2002 7:07 AM
> > To: Brandon Ehle
> > Cc: Subversion Dev list
> > Subject: RE: Repository "hung"
> > > -----Original Message-----
> > > From: Brandon Ehle [mailto:email@example.com]
> > > Sent: Thursday, December 19, 2002 4:18 AM
> > > To: Peter Howard
> > > Cc: Subversion Dev list
> > > Subject: Re: Repository "hung"
> > >
> > > Before running recover, goto the repository/db directory and run "lsof
> > > *". If you see anything accessing the files kill it. Then run
> > > recover. While recover is running you can use "lsof *" to watch its
> > > progress (in a catastrophic recovery, it will walk through
> the log files
> > > a few at a time).
> > Tried to do that, but it had fixed itself :-) I shut the
> server down last
> > night in frustration and only started it again now (9 hours
> later) and the
> > recover took about 2 seconds. Remote access works now. I _had_ done a
> > reboot last night but that didn't get things working. There were also a
> > couple of files with access permissions in the db dir, but again
> > I had fixed
> > that as I went last night, so why now?
> > So that leaves me moderately bemused as to the exact problem. But if it
> > happens again, I'll check the semaphore situation.
> Guess, what? It did it to me again today. This time I've checked the
> semaphore state prior to "fixing" (which I have failed to
> magically do yet).
> No semaphoeres, one Shared memory segment. If I leave svnadmin recover
> running long enough it dies with a seg fault.
> I had lsof running on a 20 second loop (+r 20) while svnadmin was running.
> The final loop listed the following files being accessed:
> There's 165 revisions in the repository, but it never got past the first
I was wrong there. Going back through the lsof output, it consistently gets
to log.0000000094, then spends a long time with just the files above (or a
subset) open, before hitting a segmentation fault.
I built 0.16.1 this afternoon and the behaviour of svnadmin is identical,
and repeatable; always to log.0000000094.
Anyone with an idea of what could be going on? Next step? (other than a
debug build and running it in gdb, which I'll do next)
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Jan 8 09:39:47 2003