You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Art Haas <ah...@airmail.net> on 2003/12/10 16:05:28 UTC
Apparent BerkeleyDB problem accessing repo with ra_local
Hi.
I'm once again coming to the mailing list in search of help regarding my
PythonCAD subversion repo. The machine hosting my website had moved, and
the move required getting subversion installed on the new machine. That
task has now been completed, but there is a glitch I can't resolve.
The new subversion binary fails to read the local copy of the repository
and apparently the problem is BerkeleyDB related. The repo lives on my
home machine, and I use 'rsync' to send my local copy to the remote
machine. Both subversion binaries are being linked against the 4.0.14
Berekely DB release. On my local machine I'm the only user, so I'm safe
using rsync to send the repo to the remote machine.
When trying to do 'svn ls' on the remote machine I see this:
$ svn ls file:///path/to/svnrepo
svn: Unable to open an ra_local session to URL
svn: Unable to open repository 'file:///path/to/svnrepo'
svn: Berkeley DB error while opening environment for filesystem
/path/to/svnrepo/db:
Resource temporarily unavailable
$
I own the files on both machines, and the read/write permissions are
identical on both machines as well. Back in January I'd had this exact
same problem which was due to using different Berekely DB releases, but
this I know that the version are both 4.0.14, though on my machine it is
the current Debian libdb-4.0 package, and the remote machine is a RedHat
db4 package.
Doing an 'strace' on the troublesome repo shows that subversion gets
stuck reading the 'db/__db.001' file inside the repository. None of the
other '__db' files are ever opened.
My local machine is running 0.34.0+, as it was built a few revisions
after the official 0.34.0 release. The remote machine is running the
current repository development release, as it was built yesterday (and
rebuilt today, FWIW).
Ideas and suggestions welcomed. Thanks in advance.
Art Haas
--
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.
-Thomas Jefferson to James Smith, 1822
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Apparent BerkeleyDB problem accessing repo with ra_local
Posted by Art Haas <ah...@airmail.net>.
On Wed, Dec 10, 2003 at 05:18:48PM +0000, Philip Martin wrote:
> "Art Haas" <ah...@airmail.net> writes:
>
> It could be a NPTL problem as Greg suggested, however
>
> > When trying to do 'svn ls' on the remote machine I see this:
>
> "remote"
>
> > $ svn ls file:///path/to/svnrepo
>
> "file:"
>
> > svn: Unable to open an ra_local session to URL
> > svn: Unable to open repository 'file:///path/to/svnrepo'
> > svn: Berkeley DB error while opening environment for filesystem
> > /path/to/svnrepo/db:
> > Resource temporarily unavailable
>
> Are you trying to use ra_local to access a repository on a network
> partition? You need to run a Subversion server to access a repository
> over a network.
I did the 'svn ls' locally to test the repo and see if it was readable
for someone accessing it locally on the remote machine. For remote access
I've got Apache configured to make the repo available, and after doing
the 'svnadmin' trick of rebuilding the files the repo is available over
the net again. On my home machine I get this:
$ svn ls http://subversion.pythoncad.org:9000/svn
pythoncad/
$
I'll be investigating the problem with the BerkeleyDB files in the
coming days. I've tried downloading and building my own copy of the
db-4.0 libraries, and subversion failed with that as well. The important
thing is that the repository is again publically available.
Art Haas
--
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.
-Thomas Jefferson to James Smith, 1822
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Apparent BerkeleyDB problem accessing repo with ra_local
Posted by Philip Martin <ph...@codematters.co.uk>.
"Art Haas" <ah...@airmail.net> writes:
It could be a NPTL problem as Greg suggested, however
> When trying to do 'svn ls' on the remote machine I see this:
"remote"
> $ svn ls file:///path/to/svnrepo
"file:"
> svn: Unable to open an ra_local session to URL
> svn: Unable to open repository 'file:///path/to/svnrepo'
> svn: Berkeley DB error while opening environment for filesystem
> /path/to/svnrepo/db:
> Resource temporarily unavailable
Are you trying to use ra_local to access a repository on a network
partition? You need to run a Subversion server to access a repository
over a network.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Apparent BerkeleyDB problem accessing repo with ra_local
Posted by Art Haas <ah...@airmail.net>.
On Wed, Dec 10, 2003 at 12:45:50PM -0500, Greg Hudson wrote:
> On Wed, 2003-12-10 at 12:05, Art Haas wrote:
> > Well, that sort-of worked. The '__db' files were recreated, then
> > subversion can read them, but the program ends with an 'Aborted' message
> > like so:
> >
> > $ svn ls file:///path/to/svnrepo
> > pythoncad/
> > Aborted
>
> > Maybe this error is just a bug in the current code that will be fixed in
> > a day or two.
>
> More likely, BDB doesn't like something about your database and called
> abort(). gdb might shed some light on the situation.
I'll try and poke around a bit in the next couple of days and see if I
can figure out anything.
> > My Debian box has an NPTL based libc, so if the problem is
> > LinuxThreads/NPTL in origin I would think it would show up here as well.
>
> So, what I meant by a LinuxThreads/NTPL issue is this: BDB maps a shared
> memory region in the __db files and treats the resulting memory as
> containing a mutex, among other things. If you copy the DB from one
> platform to another and the representations of pthread_mutex_t are
> different, then attempting to open the database will fail in a cryptic
> manner. As I said, very brittle.
>
> So, if one of your machines uses LinuxThreads and the other uses NPTL,
> you can't copy databases between them (although recovery might help).
> The same might apply to different versions of LinuxThreads and NPTL.
Would the relevant parts of some 'strace'd output be worth posting to
the list?
> > A look at the 'changelog.Debian.gz' file shows that the libdb4.0
> > package has a "patch to allow db_recover to recover a wedged db_env".
> > I don't think this patch is in the remote machine's libdb, but that
> > machine may have other patches not on this machine.
>
> A brief look at Debian's and Red Hat's patches to db 4.0 does not
> suggest that they have changed the shared memory region representation
> from stock BDB, but they may still have different mutex representations.
As the transition from LinuxThreads to NPTL has started, is there any
sort of test code that can added into subversion to possibly notify
users that copying the repository from one machine to another like I'm
doing can cause problems?
If I'm able to figure out anything regarding the libdb issue I'll send
an e-mail to the list.
Art Haas
--
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.
-Thomas Jefferson to James Smith, 1822
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Apparent BerkeleyDB problem accessing repo with ra_local
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2003-12-10 at 12:05, Art Haas wrote:
> Well, that sort-of worked. The '__db' files were recreated, then
> subversion can read them, but the program ends with an 'Aborted' message
> like so:
>
> $ svn ls file:///path/to/svnrepo
> pythoncad/
> Aborted
> Maybe this error is just a bug in the current code that will be fixed in
> a day or two.
More likely, BDB doesn't like something about your database and called
abort(). gdb might shed some light on the situation.
> My Debian box has an NPTL based libc, so if the problem is
> LinuxThreads/NPTL in origin I would think it would show up here as well.
So, what I meant by a LinuxThreads/NTPL issue is this: BDB maps a shared
memory region in the __db files and treats the resulting memory as
containing a mutex, among other things. If you copy the DB from one
platform to another and the representations of pthread_mutex_t are
different, then attempting to open the database will fail in a cryptic
manner. As I said, very brittle.
So, if one of your machines uses LinuxThreads and the other uses NPTL,
you can't copy databases between them (although recovery might help).
The same might apply to different versions of LinuxThreads and NPTL.
> A look at the 'changelog.Debian.gz' file shows that the libdb4.0
> package has a "patch to allow db_recover to recover a wedged db_env".
> I don't think this patch is in the remote machine's libdb, but that
> machine may have other patches not on this machine.
A brief look at Debian's and Red Hat's patches to db 4.0 does not
suggest that they have changed the shared memory region representation
from stock BDB, but they may still have different mutex representations.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Apparent BerkeleyDB problem accessing repo with ra_local
Posted by Art Haas <ah...@airmail.net>.
On Wed, Dec 10, 2003 at 11:23:20AM -0500, Greg Hudson wrote:
> I think you're running into a conflict between LinuxThreads and NPTL,
> though I can't be sure. The relevant BDB code is very brittle. Try
> "svnadmin recover" on the repository; if that doesn't work, assume you
> have to transfer the repository through dump and load.
>
> (Repeat after me: I hate Berkeley DB. I hate Berkeley DB.)
>
Well, that sort-of worked. The '__db' files were recreated, then
subversion can read them, but the program ends with an 'Aborted' message
like so:
$ svn ls file:///path/to/svnrepo
pythoncad/
Aborted
$
Maybe this error is just a bug in the current code that will be fixed in
a day or two.
My Debian box has an NPTL based libc, so if the problem is
LinuxThreads/NPTL in origin I would think it would show up here as well.
A look at the 'changelog.Debian.gz' file shows that the libdb4.0
package has a "patch to allow db_recover to recover a wedged db_env".
I don't think this patch is in the remote machine's libdb, but that
machine may have other patches not on this machine.
Always doing an 'svnadmin recover' is a bit of a pain. More
investigation is required. The Berkeley DB libraries _are_ proving to be
quite a tricky lot to deal with ...
Art Haas
--
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.
-Thomas Jefferson to James Smith, 1822
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Apparent BerkeleyDB problem accessing repo with ra_local
Posted by Greg Hudson <gh...@MIT.EDU>.
I think you're running into a conflict between LinuxThreads and NPTL,
though I can't be sure. The relevant BDB code is very brittle. Try
"svnadmin recover" on the repository; if that doesn't work, assume you
have to transfer the repository through dump and load.
(Repeat after me: I hate Berkeley DB. I hate Berkeley DB.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org