Hi,
Another similar issue:
While simultaneously doing a large commit and dumping the repository
with svn dump, yet more repository errors:
svn: Berkeley DB error while reading node revision for filesystem
foo/db:
DB_RUNRECOVERY: Fatal error, run database recovery
svn: Berkeley DB error while closing 'nodes' database for filesystem
foo/db:
DB_RUNRECOVERY: Fatal error, run database recovery
svn: Commit failed (details follow):
svn: PUT of
/source/foo/!svn/wrk/a63cadc8-23e0-0310-9a9d-f5262b83dea4/...: Could not
read status line: Secure connection truncated (https://...)
svn: PROPFIND request failed on '...'
svn: PROPFIND of '...': 500 Internal Server Error (https://...)
hmm, now that I think about it the cron job was running svn dump as
root, which is probably not the best way of doing that, and there was a
root owned log file in the repository, which may have caused the
internal server error, but I didn't think that svn dump should be
generating any log files, everything else that accesses the repository
directly is executed by the apache user.
Matt
On Thu, 2004-07-22 at 22:02, Matthew Rich wrote:
> Hi,
> I was running this script to mess with a fairly large amount of data in
> a working directory check status, commit, tag (copy), etc., and during
> one commit the server seemed to stall, at least the svn client hung
> about twiddling it's thumbs in the commit and would not respond to
> anything short of SIGKILL, in which case (as you might expect) it
> promptly went defunct.
> During all this (and after), everything that touched the repository
> seemed to hang in an identical state, most notably viewcvs.cgi which
> accesses the repository directly, so it doesn't seem to be mod_dav_svn
> specific, which is what I was using to do the commit (Fedora Core 2
> build btw). Restarting httpd seemed to fix the problem with viewcvs et.
> al. hanging, at which point the server promptly reported that the
> repository was in a bad state and I needed to run recover. This fixed
> the problem, completeing the commit that had been in progress, but what
> concerns me is why it happened in the first place.
>
> It seemed to me to possibly be the culmination of various things:
> 1) prolonged intensive commit
> 2) concurrent accesses (from the same and other RA mechs)
> 3) and probably the actual cause: Netbackup running
>
> or I could have just killed it while it was trying to time-out and it
> evidently left the repository in a bad state
>
> I noticed one issue in the ml about veritas hosing a repository, but I
> wonder if anyone has any reason to believe that it is safe to run
> Netbackup, or is there a bug in Subversion, or Netbackup even lol? In
> any case I thought this might be of interest; it seemed like a locking
> problem ... perhaps.
> Cheers,
>
> Matt
>
>
> p.s.
> grr, ok now I'm seeing this kind of thing on checkout, and netbackup
> certainly isn't running:
> svn: REPORT ... !svn/vcc/default': Could not read chunk size: Secure
> connection truncated
>
> p.p.s
> ok a couple of bounces and a recover and it went back to normal, for the
> moment. Possibly something not SVN related, but I'm almost certain that
> it was just the problem repository, and not any of the others.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 27 23:01:36 2004