You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Eric S. Raymond" <es...@snark.thyrsus.com> on 2004/09/09 23:26:21 UTC
Fatal error while attempting recovery
What does one do when "svnadmin recover" fails with a fatal error?
esr@sheep:~> svnadmin recover /svnroot/repos/gpsd
Please wait; recovering the repository may take some time...
svn: DB_RUNRECOVERY: Fatal error, run database recovery
esr@sheep:~>
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
A ``decay in the social contract'' is detectable; there is a growing
feeling, particularly among middle-income taxpayers, that they are not
getting back, from society and government, their money's worth for
taxes paid. The tendency is for taxpayers to try to take more control
of their finances... -- IRS Strategic Plan, (May 1984)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Fatal error while attempting recovery
Posted by Max Bowsher <ma...@ukf.net>.
Eric S. Raymond wrote:
> esr@sheep:/svnroot/repos/gpsd/db> ls -l
> total 6441
> -rw-rw-r-- 1 wwwrun gpsd 196608 2004-09-10 02:12 changes
> -rw-rw-r-- 1 wwwrun gpsd 8192 2004-09-10 02:12 copies
> -rw-rw-r-- 1 wwwrun gpsd 1738 2004-08-18 12:34 DB_CONFIG
> -rw-rw-r-- 1 wwwrun gpsd 1048540 2004-09-10 01:19 log.0000000039
> -rw-r--r-- 1 wwwrun gpsd 8556 2004-09-10 01:58 log.0000000040
> -rw-rw-r-- 1 wwwrun gpsd 299008 2004-09-10 02:12 nodes
> -rw-rw-r-- 1 wwwrun gpsd 385024 2004-09-10 02:12
> representations
> -rw-rw-r-- 1 wwwrun gpsd 24576 2004-09-10 02:12 revisions
> -rw-rw-r-- 1 wwwrun gpsd 4317184 2004-09-10 02:12 strings
> -rw-rw-r-- 1 wwwrun gpsd 286720 2004-09-10 02:12 transactions
> -rw-rw-r-- 1 wwwrun gpsd 8192 2004-09-10 02:12 uuids
>
> Would I be correct in thinking the group write bit for log.0000000040
> ought to be on? I think that would explain all the messages I've seen.
Yes, you are correct.
Yes, it does explain the (woefully vague) error messages you've been seeing.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Fatal error while attempting recovery
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "Eric" == Eric S Raymond <es...@thyrsus.com> writes:
Eric> Yup, looks like it. I wonder what scrambled that bit?
Most probably some other kind of access, with umask==0022.
hth,
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Fatal error while attempting recovery
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Ben Collins-Sussman <su...@collab.net>:
> No, not root, but you do need read/write access to the entire
> repository. It's pretty clear that you don't. 'db_recover' is giving
> you all sorts of permission errors trying to open db files... that's
> probably the reason 'svnadmin recover' failed in the first place.
>
> The standard wisdom is: run recovery as the user which owns the repository.
>
> (Don't run as root... you're likely to accidentally change file
> ownership and make it inaccessible for other users.)
It appears that ownership of the files has been grabbed by something called
wwwrun, which is probably some berlios.de server process thing...ahh, now
look at this:
esr@sheep:/svnroot/repos/gpsd/db> ls -l
total 6441
-rw-rw-r-- 1 wwwrun gpsd 196608 2004-09-10 02:12 changes
-rw-rw-r-- 1 wwwrun gpsd 8192 2004-09-10 02:12 copies
-rw-rw-r-- 1 wwwrun gpsd 1738 2004-08-18 12:34 DB_CONFIG
-rw-rw-r-- 1 wwwrun gpsd 1048540 2004-09-10 01:19 log.0000000039
-rw-r--r-- 1 wwwrun gpsd 8556 2004-09-10 01:58 log.0000000040
-rw-rw-r-- 1 wwwrun gpsd 299008 2004-09-10 02:12 nodes
-rw-rw-r-- 1 wwwrun gpsd 385024 2004-09-10 02:12 representations
-rw-rw-r-- 1 wwwrun gpsd 24576 2004-09-10 02:12 revisions
-rw-rw-r-- 1 wwwrun gpsd 4317184 2004-09-10 02:12 strings
-rw-rw-r-- 1 wwwrun gpsd 286720 2004-09-10 02:12 transactions
-rw-rw-r-- 1 wwwrun gpsd 8192 2004-09-10 02:12 uuids
Would I be correct in thinking the group write bit for log.0000000040
ought to be on? I think that would explain all the messages I've seen.
esr@sheep:~> db_recover -vech /svnroot/repos/gpsd/db
db_recover: Finding last valid log LSN: file: 40 offset 8556
db_recover: Recovery starting from [39][28]
db_recover: /svnroot/repos/gpsd/db/log.0000000040: log file open failed: Permission denied
db_recover: PANIC: Permission denied
db_recover: DB_ENV->log_put: 40: DB_RUNRECOVERY: Fatal error, run database recovery
db_recover: txn_checkpoint: log failed at LSN [40 8474] DB_RUNRECOVERY: Fatal error, run database recovery
db_recover: PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
db_recover: /svnroot/repos/gpsd/db/log.0000000040: log file open failed: Permission denied
db_recover: PANIC: Permission denied
db_recover: DB_ENV->log_put: 40: DB_RUNRECOVERY: Fatal error, run database recovery
db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run database recovery
Yup, looks like it. I wonder what scrambled that bit?
Is the "emergency recovery" procedure documented anywhere?
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Fatal error while attempting recovery
Posted by Ben Collins-Sussman <su...@collab.net>.
Eric S. Raymond wrote:
> Do I have to be root for this? On berlios.de I'm not an admin.
No, not root, but you do need read/write access to the entire
repository. It's pretty clear that you don't. 'db_recover' is giving
you all sorts of permission errors trying to open db files... that's
probably the reason 'svnadmin recover' failed in the first place.
The standard wisdom is: run recovery as the user which owns the repository.
(Don't run as root... you're likely to accidentally change file
ownership and make it inaccessible for other users.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Fatal error while attempting recovery
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
C. Michael Pilato <cm...@collab.net>:
> "Eric S. Raymond" <es...@snark.thyrsus.com> writes:
>
> > What does one do when "svnadmin recover" fails with a fatal error?
> >
> > esr@sheep:~> svnadmin recover /svnroot/repos/gpsd
> > Please wait; recovering the repository may take some time...
> > svn: DB_RUNRECOVERY: Fatal error, run database recovery
> > esr@sheep:~>
>
> Obey the instructions, of course. Oh. Wait. :-)
>
> Try running a catastrophic recover:
>
> $ /path/to/BDB4.x/bin/db_recover -vech /svnroot/repos/gpsd/db
esr@sheep:~> svnadmin recover /svnroot/repos/gpsd
Please wait; recovering the repository may take some time...
svn: DB_RUNRECOVERY: Fatal error, run database recovery
esr@sheep:~> db_recover -vech /svnroot/repos/gpsd/db
db_recover: Finding last valid log LSN: file: 40 offset 5152
db_recover: Recovery starting from [39][28]
db_recover: /svnroot/repos/gpsd/db/log.0000000040: log file open failed: Permission denied
db_recover: PANIC: Permission denied
db_recover: DB_ENV->log_put: 40: DB_RUNRECOVERY: Fatal error, run database recovery
db_recover: txn_checkpoint: log failed at LSN [40 5070] DB_RUNRECOVERY: Fatal error, run database recovery
db_recover: PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
db_recover: /svnroot/repos/gpsd/db/log.0000000040: log file open failed: Permission denied
db_recover: PANIC: Permission denied
db_recover: DB_ENV->log_put: 40: DB_RUNRECOVERY: Fatal error, run database recovery
db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run database recovery
esr@sheep:~>
Do I have to be root for this? On berlios.de I'm not an admin.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Fatal error while attempting recovery
Posted by "C. Michael Pilato" <cm...@collab.net>.
"Eric S. Raymond" <es...@snark.thyrsus.com> writes:
> What does one do when "svnadmin recover" fails with a fatal error?
>
> esr@sheep:~> svnadmin recover /svnroot/repos/gpsd
> Please wait; recovering the repository may take some time...
> svn: DB_RUNRECOVERY: Fatal error, run database recovery
> esr@sheep:~>
Obey the instructions, of course. Oh. Wait. :-)
Try running a catastrophic recover:
$ /path/to/BDB4.x/bin/db_recover -vech /svnroot/repos/gpsd/db
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org