Peter Thomas <pjt9@case.edu> wrote on 01/07/2007 07:27:54 PM:
> Dear Subversion Users:
>
> I seem to have a corrupted svn database that svnadmin recover was not
> able to handle.
> Following the instructions in the SVN book, I am sending details to
> the users list.
Greetings! As there has been no activity one this thread, and I
am interested in this fun little subject, I am wondering if you have
already found a solution to your problem. If not, I hope what I say here
will be helpful.
> <<<snip>>>
>
> > server:/projects/multiunit svnowner$ svnadmin recover ./
> > Repository lock acquired.
> > Please wait; recovering the repository may take some time...
> > svn: DB_RUNRECOVERY: Fatal error, run database recovery
> > svn: bdb: db/log.0000004644: log file open failed: Permission denied
> > svn: bdb: PANIC: Permission denied
> > svn: bdb: DB_ENV->log_put: 4644: DB_RUNRECOVERY: Fatal error, run
> > database recovery
> > svn: bdb: txn_checkpoint: log failed at LSN [4644 328702]
> > DB_RUNRECOVERY: Fatal error, run database recovery
> > svn: bdb: PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
> > svn: bdb: db/log.0000004644: log file open failed: Permission denied
> > svn: bdb: PANIC: Permission denied
> > svn: bdb: DB_ENV->log_put: 4644: DB_RUNRECOVERY: Fatal error, run
> > database recovery
> > svn: bdb: PANIC: fatal region error detected; run recovery
> <<<snip>>>
>
> On Jan 5, 2007 I initiated a backup of the repository /projects/
> multiunit along with a few others to an external hardrive using
> rsync. The database is about 4 Gb so it was going to take a while.
> At about the same time one of my students tried making a new checkout
> of /projects/multiunit. He mistakenly ssh'd into the server and
> tried svn co svn+ssh://server_address/projects/multiunit from his
> home directory. At that point I had neglected to add him the svn
> authorized users group. Later he tried svn co svn+ssh://
> server_address/projects/multiunit on his own local machine. After I
> added him to the svn authorized user group on the server, he tried
> again and got the Berkeley DB error I quoted above.
I don't suppose you happen to know what error the student received
when he made his first (failed) checkout attempt?
Two immediate thoughts, both of which you may have already
handled, but which bear repeating anyway. First, regarding the backup,
are you backing up the files in the appropriate order, as is required by
BerkeleyDB tables in active use? I know that there is a document
somewhere describing the proper method for an on-line backup of a BDB
database, but I do not know of its location. I do, however, know that
`svnadmin hotcopy` will work. As a substitute, you might wish to consider
a script that generates an incremental backup every time a commit (or
revprop change) takes place (`svnadmin dump --incremental --revision
XYZ`), although doing both incremental and full backups isn't a bad idea!
Second, for all of these different user accounts that are touching
the repository files directly: (1) Is each user in the appropriate group,
where the "appropriate group" is the group owner of the repository
database files, and (2) are all of them using the appropriate umasks, so
that those who need to can have access (both read and write) to the
database, by virtue of their membership in the appropriate group?
> One other piece of information: the file db/log.0000004644 owner is
> set to me (pjthomas) rather than the repository owner. But this is
> true in other repositories that are not experiencing problems.
More than the exact owner, I am wondering (a) what the permissions
are, and (b) which accounts actually access the repository files; for
svn:// and svn+ssh://, that would mean "which account is being used to
execute `svnserve`", and for http:// and https:// (if they are used),
"which account is being used to execute Apache"?, and "which users are
accessing the repository locally?". That would then bring me back to the
question of the umask, and permissions. If said log file was owned by
you, and not the account that was running the recovery, did the account
running the recovery have read/write permissions for the log file?
> I plan to try restoring /projects/multiunit wholesale from my most
> recent backup, and then checking in the files on my local machine
> which are the most recent working copies. Any suggestions or ideas
> about what went wrong with the database would be most welcome!
>
> <<<snip>>>
Although I haven't seen everything, my guess is this: The account
running the svnserve program did not have write permissions for (at the
very least) the file 'db/log.0000004644'. I noticed the phrase
"DB_ENV->log_put" in the output of the recovery attempt. 'log_put' sounds
like a function name, possibly including a write operation of some kind. A
search for "bdb log_put" confirmed this.
In any event, I'd say it's a permissions problem, of some sort. My
suggestion would be twofold. First, these four commands should set up the
appropriate permissions for a BDB-based Subversion repository with
multiple users in a common group. Replace $USER with the username of the
repository administrator (who runs the recovery); $GROUP is the name of
the group that is used to control access to the repository. Run the
commands as $USER, within the repository directory (which contains the
'format' and 'README.txt' files). $USER will need to be an Administrator
during this process, for the `sudo` command to work.
sudo chown -R $USER:$GROUP . (1) Ensure
that $USER owns everything, with $GROUP as the group
sudo chmod -R ug=rw,o-rwx . (2) Ensure
that $USER and $GROUP (and only them) can read and write all files
sudo chmod ug+x,g+s . conf dav db hooks locks (3) Ensure that
$USER and $GROUP can enter all directories. Also ensure that all files
created/modified have $GROUP set as the file's group
svnadmin recover . (4)
Attempt to repair the BDB problems
(NOTE: These commands are for BDB-based repositories only, not FSFS!)
After that, before you (or anyone else) touch the repository, make
sure that you have the correct umask. Users who access the repository via
"file://" should run `umask 002` first. I do suggest that you attempt to
check out the repository, locally, to ensure that everything is OK (fix
your umask first).
For the users who access the repository via "svn://" or
"svn+ssh://", I direct you to the command `svnwrap`, which has one
purpose: Move the real `svnserve` and `svnadmin` (and possibly also
`svn`) into a hidden location, replacing their public faces with a script
that sets the proper umask (002) before calling the now-hidden commands. I
refer you to <
http://lists.alioth.debian.org/pipermail/pkg-subversion-maintainers/2006-April/000650.html
> for more information, <
http://www.baizid.org/cgi-bin/dwww?type=runman&location=SVNWRAP/1> for the
man page, and <http://packages.ubuntu.com/dapper/admin/subversion-tools>
for the package containing the program (under "Download subversion-tools",
click on 'All').
If any users use "http://" or "https://", it is up to you to
ensure that Apache is being run with the proper umask.
Once proper umasks are set, I'd suggest doing some typical
operations to test. Don't be afraid to do a few commits, as long as you
remember to undo them immediately! Simply having several users create,
commit, modify, and delete a file or two would be enough!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 12 10:21:03 2007