You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Aleksandr Sidorenko <as...@espeo.com> on 2011/11/14 17:06:49 UTC
"Couldn't open rep-cache database" (post commit FS processing)
Hi everyone,
I've searched the mailing list archive for this error, but results were pretty limited. I also haven't found a fix elsewhere on the web.
The exact error I am getting upon a commit is:
Sending xxxxxxx
Transmitting file data .
Committed revision xxxxxxx.
Warning: post commit FS processing had error:
Couldn't open rep-cache database
The commit itself is done properly. On the SVN server, the permissions on db/rep-cache.db are correct (read/writeable by the correct user/group used by the Apache web server).
Of note, this error started right after we updated the server from 1.6.12 to 1.7.1.
Any help would be greatly appreciated!
Aleksandr Sidorenko
Administrateur systèmes/réseaux • System/Network Administrator
Espeo Inc.
2000, ave McGill College, bureau 230
Montréal, Québec (H3A 3H3)
www.espeo.com
asidorenko@espeo.com
514-905-1268 #234
Re: "Couldn't open rep-cache database" (post commit FS processing)
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Aleksandr Sidorenko,
am Montag, 14. November 2011 um 18:04 schrieben Sie:
> Since posting the question, I tried using "svnserve" instead of
> Apache (the mod_dav_svn module), and the error does NOT occur in
> this case (we would still prefer to stick with mod_dav_svn).
How did you manage permissions using svnserver? You mentioned a group
which you gave read/write access for the file. Did you made
svnserve-deamon member of thet group or did something else? I thought
of lock files rep-cache.db which may be not created during
insufficient permissions on the parent directory. But I don't know if
SQLite works this way.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon.............030-2 1001-310
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: "Couldn't open rep-cache database" (post commit FS processing)
Posted by Aleksandr Sidorenko <as...@cashontime.com>.
On 2011-11-16, at 10:41 , Bert Huijben wrote:
>>
>> -----Original Message-----
>> From: Philip Martin [mailto:philip.martin@wandisco.com]
>> Sent: woensdag 16 november 2011 16:37
>> To: Aleksandr Sidorenko
>> Cc: <us...@subversion.apache.org>
>> Subject: Re: "Couldn't open rep-cache database" (post commit FS
>> processing)
>>
>> Aleksandr Sidorenko <as...@cashontime.com> writes:
>>
>>> But it seems it's not this error that is triggered; it's the one a few
> lines down
>> (I changed the error message to detect it):
>>>
>>> #if APR_HAS_THREADS
>>> /* Wait for whichever thread is performing initialization to finish.
> */
>>> /* XXX FIXME: Should we have a maximum wait here, like we have in
>>> the Windows file IO spinner? */
>>> else while (status != SVN_ATOMIC_INITIALIZED)
>>> {
>>> if (status == SVN_ATOMIC_INIT_FAILED)
>>> return svn_error_create(SVN_ERR_ATOMIC_INIT_FAILURE, NULL,
>>> "Couldn't perform atomic
> initialization");
>>
>> Wow! The atomic operations are failing! Which OS? Which distribution?
>> Which complier? 32-bit or 64-bit?
>
> You get in this branch if a previous atomic initialization call failed: the
> callback function failed and returned an error. This result is then ignored
> in some code paths.
>
> It is most likely not caused by the atomic operations failing itself, but
> more likely by an initialization error in a third party library.
Any idea which library might be involved? I only used the default configuration options when building from source:
./configure --with-sqlite=/usr/local
Using sqlite 3.7.8.
Re: "Couldn't open rep-cache database" (post commit FS processing)
Posted by Philip Martin <ph...@wandisco.com>.
Aleksandr Sidorenko <as...@cashontime.com> writes:
> On 2011-11-16, at 11:15 , Philip Martin wrote:
>
>>> ...
>>
>> Try this patch:
>>
>> Index: subversion/libsvn_fs_fs/fs_fs.c
>> ===================================================================
>> --- subversion/libsvn_fs_fs/fs_fs.c (revision 1202738)
>> +++ subversion/libsvn_fs_fs/fs_fs.c (working copy)
>> @@ -5580,6 +5580,7 @@
>> svn_error_t *err;
>> err = svn_fs_fs__get_rep_reference(&old_rep, b->fs, rep->sha1_checksum,
>> b->parent_pool);
>> + SVN_ERR(err);
>> /* ### Other error codes that we shouldn't mask out? */
>> if (err == SVN_NO_ERROR
>> || err->apr_err == SVN_ERR_FS_CORRUPT
>>
>> To make the first error hard. Then try committing a file over ra_local:
>>
>> $ rm -rf repo && svnadmin create repo
>> $ svn import -mm repo/format file://`pwd`/repo/f
>>
>> That should make the error explicit.
>
> I should note that the error does NOT occur locally, or if I use svnserve. It only occurs for commits done via HTTP (the mod_dav_svn module).
>
> For local commits (or via svnserve), the repo/db/rep-cache.db file is touched as expected (the modification date changes).
That should work for apache as well, but only the first commit after
apache is started. Subsequent commits will just give the atomic error
message.
--
Philip
Re: "Couldn't open rep-cache database" (post commit FS processing)
Posted by Aleksandr Sidorenko <as...@cashontime.com>.
On 2011-11-16, at 11:15 , Philip Martin wrote:
>> ...
>
> Try this patch:
>
> Index: subversion/libsvn_fs_fs/fs_fs.c
> ===================================================================
> --- subversion/libsvn_fs_fs/fs_fs.c (revision 1202738)
> +++ subversion/libsvn_fs_fs/fs_fs.c (working copy)
> @@ -5580,6 +5580,7 @@
> svn_error_t *err;
> err = svn_fs_fs__get_rep_reference(&old_rep, b->fs, rep->sha1_checksum,
> b->parent_pool);
> + SVN_ERR(err);
> /* ### Other error codes that we shouldn't mask out? */
> if (err == SVN_NO_ERROR
> || err->apr_err == SVN_ERR_FS_CORRUPT
>
> To make the first error hard. Then try committing a file over ra_local:
>
> $ rm -rf repo && svnadmin create repo
> $ svn import -mm repo/format file://`pwd`/repo/f
>
> That should make the error explicit.
I should note that the error does NOT occur locally, or if I use svnserve. It only occurs for commits done via HTTP (the mod_dav_svn module).
For local commits (or via svnserve), the repo/db/rep-cache.db file is touched as expected (the modification date changes).
Re: "Couldn't open rep-cache database" (post commit FS processing)
Posted by Aleksandr Sidorenko <as...@cashontime.com>.
On 2011-11-16, at 11:37 , Aleksandr Sidorenko wrote:
> On 2011-11-16, at 11:15 , Philip Martin wrote:
>
>> Aleksandr Sidorenko <as...@cashontime.com> writes:
>>
>>> The sqlite command worked (I see the expected output), but I suspect that's because the rep-cache.db file was already there (since 1.6.12). If I move it, though, the file is NOT recreated.
>>>
>>> greping through /proc/xxx/maps gives me the following:
>>>
>>> 2a96fc4000-2a97058000 r-xp 00000000 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6
>>> 2a97058000-2a97158000 ---p 00094000 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6
>>> 2a97158000-2a9715c000 rw-p 00094000 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6
>>>
>>> sqlite was built with default options, but "--enable-threadsafe" defaults to "yes" if it's not used, so I guess it *is* built with thread support?
>>
>> Try this patch:
>>
>> Index: subversion/libsvn_fs_fs/fs_fs.c
>> ===================================================================
>> --- subversion/libsvn_fs_fs/fs_fs.c (revision 1202738)
>> +++ subversion/libsvn_fs_fs/fs_fs.c (working copy)
>> @@ -5580,6 +5580,7 @@
>> svn_error_t *err;
>> err = svn_fs_fs__get_rep_reference(&old_rep, b->fs, rep->sha1_checksum,
>> b->parent_pool);
>> + SVN_ERR(err);
>> /* ### Other error codes that we shouldn't mask out? */
>> if (err == SVN_NO_ERROR
>> || err->apr_err == SVN_ERR_FS_CORRUPT
>>
>> To make the first error hard. Then try committing a file over ra_local:
>>
>> $ rm -rf repo && svnadmin create repo
>> $ svn import -mm repo/format file://`pwd`/repo/f
>>
>> That should make the error explicit.
>
> Ok, I tried this patch, and this is the error I get:
>
> svn: E200030: SQLite compiled for 3.7.9, but running with 3.3.17
>
> So, it seems the sqlite version I compiled is NOT getting used; it's taking the older one. I suspect it's not looking in the right place (/usr/lib64 vs /usr/local/lib). I'm going to investgate this.
RESOLVED.
The problem was that our Apache server was loading the PHP module *before* the mod_dav_svn module, and PHP uses an old sqlite library. Reversing the load order eliminates the error (see http://www.snowbotic.com/archives/61).
Thanks everyone; it really helped me pin this down!
Re: "Couldn't open rep-cache database" (post commit FS processing)
Posted by Aleksandr Sidorenko <as...@cashontime.com>.
On 2011-11-16, at 11:15 , Philip Martin wrote:
> Aleksandr Sidorenko <as...@cashontime.com> writes:
>
>> The sqlite command worked (I see the expected output), but I suspect that's because the rep-cache.db file was already there (since 1.6.12). If I move it, though, the file is NOT recreated.
>>
>> greping through /proc/xxx/maps gives me the following:
>>
>> 2a96fc4000-2a97058000 r-xp 00000000 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6
>> 2a97058000-2a97158000 ---p 00094000 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6
>> 2a97158000-2a9715c000 rw-p 00094000 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6
>>
>> sqlite was built with default options, but "--enable-threadsafe" defaults to "yes" if it's not used, so I guess it *is* built with thread support?
>
> Try this patch:
>
> Index: subversion/libsvn_fs_fs/fs_fs.c
> ===================================================================
> --- subversion/libsvn_fs_fs/fs_fs.c (revision 1202738)
> +++ subversion/libsvn_fs_fs/fs_fs.c (working copy)
> @@ -5580,6 +5580,7 @@
> svn_error_t *err;
> err = svn_fs_fs__get_rep_reference(&old_rep, b->fs, rep->sha1_checksum,
> b->parent_pool);
> + SVN_ERR(err);
> /* ### Other error codes that we shouldn't mask out? */
> if (err == SVN_NO_ERROR
> || err->apr_err == SVN_ERR_FS_CORRUPT
>
> To make the first error hard. Then try committing a file over ra_local:
>
> $ rm -rf repo && svnadmin create repo
> $ svn import -mm repo/format file://`pwd`/repo/f
>
> That should make the error explicit.
Ok, I tried this patch, and this is the error I get:
svn: E200030: SQLite compiled for 3.7.9, but running with 3.3.17
So, it seems the sqlite version I compiled is NOT getting used; it's taking the older one. I suspect it's not looking in the right place (/usr/lib64 vs /usr/local/lib). I'm going to investgate this.
Re: "Couldn't open rep-cache database" (post commit FS processing)
Posted by Philip Martin <ph...@wandisco.com>.
Aleksandr Sidorenko <as...@cashontime.com> writes:
> The sqlite command worked (I see the expected output), but I suspect that's because the rep-cache.db file was already there (since 1.6.12). If I move it, though, the file is NOT recreated.
>
> greping through /proc/xxx/maps gives me the following:
>
> 2a96fc4000-2a97058000 r-xp 00000000 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6
> 2a97058000-2a97158000 ---p 00094000 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6
> 2a97158000-2a9715c000 rw-p 00094000 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6
>
> sqlite was built with default options, but "--enable-threadsafe" defaults to "yes" if it's not used, so I guess it *is* built with thread support?
Try this patch:
Index: subversion/libsvn_fs_fs/fs_fs.c
===================================================================
--- subversion/libsvn_fs_fs/fs_fs.c (revision 1202738)
+++ subversion/libsvn_fs_fs/fs_fs.c (working copy)
@@ -5580,6 +5580,7 @@
svn_error_t *err;
err = svn_fs_fs__get_rep_reference(&old_rep, b->fs, rep->sha1_checksum,
b->parent_pool);
+ SVN_ERR(err);
/* ### Other error codes that we shouldn't mask out? */
if (err == SVN_NO_ERROR
|| err->apr_err == SVN_ERR_FS_CORRUPT
To make the first error hard. Then try committing a file over ra_local:
$ rm -rf repo && svnadmin create repo
$ svn import -mm repo/format file://`pwd`/repo/f
That should make the error explicit.
--
Philip
Re: "Couldn't open rep-cache database" (post commit FS processing)
Posted by Aleksandr Sidorenko <as...@cashontime.com>.
> "Bert Huijben" <be...@qqmail.nl> writes:
>
>> You get in this branch if a previous atomic initialization call failed: the
>> callback function failed and returned an error. This result is then ignored
>> in some code paths.
>>
>> It is most likely not caused by the atomic operations failing itself, but
>> more likely by an initialization error in a third party library.
>
> Ah, yes! When we first open/read the rep-cache during the commit the
> failure is not treated as a hard error. The subsequent open in the
> post-commit then returns the atomic error.
>
> If the rep-cache has been setup you should see:
>
> $ sqlite3 repo/db/rep-cache.db "select * from sqlite_master"
> table|rep_cache|rep_cache|3|CREATE TABLE rep_cache ( hash TEXT NOT NULL PRIMARY KEY, revision INTEGER NOT NULL, offset INTEGER NOT NULL, size INTEGER NOT NULL, expanded_size INTEGER NOT NULL )
> index|sqlite_autoindex_rep_cache_1|rep_cache|4|
>
> I suspect you will see no output because init_sqlite has failed.
>
> I see you are using --with-sqlite=/usr/local. Did you build sqlite with
> thread support? We should check which sqlite is being picked at
> runtime: either use "ldd executable" or identify the process ID and grep
> through /proc/NNN/maps, look libsqlite.
The sqlite command worked (I see the expected output), but I suspect that's because the rep-cache.db file was already there (since 1.6.12). If I move it, though, the file is NOT recreated.
greping through /proc/xxx/maps gives me the following:
2a96fc4000-2a97058000 r-xp 00000000 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6
2a97058000-2a97158000 ---p 00094000 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6
2a97158000-2a9715c000 rw-p 00094000 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6
sqlite was built with default options, but "--enable-threadsafe" defaults to "yes" if it's not used, so I guess it *is* built with thread support?
Re: "Couldn't open rep-cache database" (post commit FS processing)
Posted by Philip Martin <ph...@wandisco.com>.
"Bert Huijben" <be...@qqmail.nl> writes:
> You get in this branch if a previous atomic initialization call failed: the
> callback function failed and returned an error. This result is then ignored
> in some code paths.
>
> It is most likely not caused by the atomic operations failing itself, but
> more likely by an initialization error in a third party library.
Ah, yes! When we first open/read the rep-cache during the commit the
failure is not treated as a hard error. The subsequent open in the
post-commit then returns the atomic error.
If the rep-cache has been setup you should see:
$ sqlite3 repo/db/rep-cache.db "select * from sqlite_master"
table|rep_cache|rep_cache|3|CREATE TABLE rep_cache ( hash TEXT NOT NULL PRIMARY KEY, revision INTEGER NOT NULL, offset INTEGER NOT NULL, size INTEGER NOT NULL, expanded_size INTEGER NOT NULL )
index|sqlite_autoindex_rep_cache_1|rep_cache|4|
I suspect you will see no output because init_sqlite has failed.
I see you are using --with-sqlite=/usr/local. Did you build sqlite with
thread support? We should check which sqlite is being picked at
runtime: either use "ldd executable" or identify the process ID and grep
through /proc/NNN/maps, look libsqlite.
--
Philip
RE: "Couldn't open rep-cache database" (post commit FS processing)
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Philip Martin [mailto:philip.martin@wandisco.com]
> Sent: woensdag 16 november 2011 16:37
> To: Aleksandr Sidorenko
> Cc: <us...@subversion.apache.org>
> Subject: Re: "Couldn't open rep-cache database" (post commit FS
> processing)
>
> Aleksandr Sidorenko <as...@cashontime.com> writes:
>
> > But it seems it's not this error that is triggered; it's the one a few
lines down
> (I changed the error message to detect it):
> >
> > #if APR_HAS_THREADS
> > /* Wait for whichever thread is performing initialization to finish.
*/
> > /* XXX FIXME: Should we have a maximum wait here, like we have in
> > the Windows file IO spinner? */
> > else while (status != SVN_ATOMIC_INITIALIZED)
> > {
> > if (status == SVN_ATOMIC_INIT_FAILED)
> > return svn_error_create(SVN_ERR_ATOMIC_INIT_FAILURE, NULL,
> > "Couldn't perform atomic
initialization");
>
> Wow! The atomic operations are failing! Which OS? Which distribution?
> Which complier? 32-bit or 64-bit?
You get in this branch if a previous atomic initialization call failed: the
callback function failed and returned an error. This result is then ignored
in some code paths.
It is most likely not caused by the atomic operations failing itself, but
more likely by an initialization error in a third party library.
Bert
Re: "Couldn't open rep-cache database" (post commit FS processing)
Posted by Aleksandr Sidorenko <as...@cashontime.com>.
On 2011-11-16, at 10:36 , Philip Martin wrote:
> Aleksandr Sidorenko <as...@cashontime.com> writes:
>
>> But it seems it's not this error that is triggered; it's the one a few lines down (I changed the error message to detect it):
>>
>> #if APR_HAS_THREADS
>> /* Wait for whichever thread is performing initialization to finish. */
>> /* XXX FIXME: Should we have a maximum wait here, like we have in
>> the Windows file IO spinner? */
>> else while (status != SVN_ATOMIC_INITIALIZED)
>> {
>> if (status == SVN_ATOMIC_INIT_FAILED)
>> return svn_error_create(SVN_ERR_ATOMIC_INIT_FAILURE, NULL,
>> "Couldn't perform atomic initialization");
>
> Wow! The atomic operations are failing! Which OS? Which distribution?
> Which complier? 32-bit or 64-bit?
Linux 2.6.9-34 (CentOS 4.3), 64-bit
gcc 3.4.5
It did work in 1.6.12; what changed?
Re: "Couldn't open rep-cache database" (post commit FS processing)
Posted by Philip Martin <ph...@wandisco.com>.
Aleksandr Sidorenko <as...@cashontime.com> writes:
> But it seems it's not this error that is triggered; it's the one a few lines down (I changed the error message to detect it):
>
> #if APR_HAS_THREADS
> /* Wait for whichever thread is performing initialization to finish. */
> /* XXX FIXME: Should we have a maximum wait here, like we have in
> the Windows file IO spinner? */
> else while (status != SVN_ATOMIC_INITIALIZED)
> {
> if (status == SVN_ATOMIC_INIT_FAILED)
> return svn_error_create(SVN_ERR_ATOMIC_INIT_FAILURE, NULL,
> "Couldn't perform atomic initialization");
Wow! The atomic operations are failing! Which OS? Which distribution?
Which complier? 32-bit or 64-bit?
--
Philip
Re: "Couldn't open rep-cache database" (post commit FS processing)
Posted by Aleksandr Sidorenko <as...@cashontime.com>.
On 2011-11-16, at 10:21 , Philip Martin wrote:
> Aleksandr Sidorenko <as...@cashontime.com> writes:
>
>> Rebuilt, now I get this message on post-commit:
>>
>> Warning: post commit FS processing had error:
>> Couldn't perform atomic initialization
>
> It could be the atomic functions failing, but more likely it's still a
> DB problem. Please add this patch as well:
>
> Index: subversion/libsvn_subr/atomic.c
> ===================================================================
> --- subversion/libsvn_subr/atomic.c (revision 1202695)
> +++ subversion/libsvn_subr/atomic.c (working copy)
> @@ -57,8 +57,7 @@
> SVN_ATOMIC_INIT_FAILED,
> SVN_ATOMIC_START_INIT);
> #endif
> - return svn_error_create(SVN_ERR_ATOMIC_INIT_FAILURE, err,
> - "Couldn't perform atomic initialization");
> + return err;
> }
> svn_atomic_cas(global_status,
> SVN_ATOMIC_INITIALIZED,
No change (same error).
But it seems it's not this error that is triggered; it's the one a few lines down (I changed the error message to detect it):
#if APR_HAS_THREADS
/* Wait for whichever thread is performing initialization to finish. */
/* XXX FIXME: Should we have a maximum wait here, like we have in
the Windows file IO spinner? */
else while (status != SVN_ATOMIC_INITIALIZED)
{
if (status == SVN_ATOMIC_INIT_FAILED)
return svn_error_create(SVN_ERR_ATOMIC_INIT_FAILURE, NULL,
"Couldn't perform atomic initialization");
Re: "Couldn't open rep-cache database" (post commit FS processing)
Posted by Philip Martin <ph...@wandisco.com>.
Aleksandr Sidorenko <as...@cashontime.com> writes:
> Rebuilt, now I get this message on post-commit:
>
> Warning: post commit FS processing had error:
> Couldn't perform atomic initialization
It could be the atomic functions failing, but more likely it's still a
DB problem. Please add this patch as well:
Index: subversion/libsvn_subr/atomic.c
===================================================================
--- subversion/libsvn_subr/atomic.c (revision 1202695)
+++ subversion/libsvn_subr/atomic.c (working copy)
@@ -57,8 +57,7 @@
SVN_ATOMIC_INIT_FAILED,
SVN_ATOMIC_START_INIT);
#endif
- return svn_error_create(SVN_ERR_ATOMIC_INIT_FAILURE, err,
- "Couldn't perform atomic initialization");
+ return err;
}
svn_atomic_cas(global_status,
SVN_ATOMIC_INITIALIZED,
--
Philip
Re: "Couldn't open rep-cache database" (post commit FS processing)
Posted by Aleksandr Sidorenko <as...@cashontime.com>.
On 2011-11-16, at 10:04 , Philip Martin wrote:
> Aleksandr Sidorenko <as...@cashontime.com> writes:
>
>> I tried changed the permissions on the repository to be more permissive, and changing the user/group of the Apache server: no help.
>>
>> I also tried recompiling from source, but that did not help either.
>>
>> To recap, I am getting this warning after every commit since we upgraded the SVN server to 1.7.1:
>>
>> Warning: post commit FS processing had error:
>> Couldn't open rep-cache database
>
> As you are building from source could you try the following patch, it
> will cause the lower level error to be returned:
>
>
> Index: subversion/libsvn_fs_fs/rep-cache.c
> ===================================================================
> --- subversion/libsvn_fs_fs/rep-cache.c (revision 1202695)
> +++ subversion/libsvn_fs_fs/rep-cache.c (working copy)
> @@ -121,7 +121,7 @@
> fs_fs_data_t *ffd = fs->fsap_data;
> svn_error_t *err = svn_atomic__init_once(&ffd->rep_cache_db_opened,
> open_rep_cache, fs, pool);
> - return svn_error_quick_wrap(err, _("Couldn't open rep-cache database"));
> + return err;
> }
>
> svn_error_t *
Rebuilt, now I get this message on post-commit:
Warning: post commit FS processing had error:
Couldn't perform atomic initialization
Re: "Couldn't open rep-cache database" (post commit FS processing)
Posted by Philip Martin <ph...@wandisco.com>.
Aleksandr Sidorenko <as...@cashontime.com> writes:
> I tried changed the permissions on the repository to be more permissive, and changing the user/group of the Apache server: no help.
>
> I also tried recompiling from source, but that did not help either.
>
> To recap, I am getting this warning after every commit since we upgraded the SVN server to 1.7.1:
>
> Warning: post commit FS processing had error:
> Couldn't open rep-cache database
As you are building from source could you try the following patch, it
will cause the lower level error to be returned:
Index: subversion/libsvn_fs_fs/rep-cache.c
===================================================================
--- subversion/libsvn_fs_fs/rep-cache.c (revision 1202695)
+++ subversion/libsvn_fs_fs/rep-cache.c (working copy)
@@ -121,7 +121,7 @@
fs_fs_data_t *ffd = fs->fsap_data;
svn_error_t *err = svn_atomic__init_once(&ffd->rep_cache_db_opened,
open_rep_cache, fs, pool);
- return svn_error_quick_wrap(err, _("Couldn't open rep-cache database"));
+ return err;
}
svn_error_t *
--
Philip
Re: "Couldn't open rep-cache database" (post commit FS processing)
Posted by Aleksandr Sidorenko <as...@cashontime.com>.
Following up…
I tried changed the permissions on the repository to be more permissive, and changing the user/group of the Apache server: no help.
I also tried recompiling from source, but that did not help either.
To recap, I am getting this warning after every commit since we upgraded the SVN server to 1.7.1:
Warning: post commit FS processing had error:
Couldn't open rep-cache database
On 2011-11-14, at 21:35 , Aleksandr Sidorenko wrote:
>>> Since posting the question, I tried using "svnserve" instead of
>>> Apache (the mod_dav_svn module), and the error does NOT occur in
>>> this case (we would still prefer to stick with mod_dav_svn).
>>
>> How did you manage permissions using svnserver? You mentioned a group
>> which you gave read/write access for the file. Did you made
>> svnserve-deamon member of thet group or did something else? I thought
>> of lock files rep-cache.db which may be not created during
>> insufficient permissions on the parent directory. But I don't know if
>> SQLite works this way.
>
> I ran the svnserver test as root, without any restrictions.
>
> But I don't think it's a permission issue on the rep-cache.db file since I even tried giving it unrestricted read/write access to be sure that wasn't the case. Could other files be involved?
Re: "Couldn't open rep-cache database" (post commit FS processing)
Posted by Aleksandr Sidorenko <as...@cashontime.com>.
>> Since posting the question, I tried using "svnserve" instead of
>> Apache (the mod_dav_svn module), and the error does NOT occur in
>> this case (we would still prefer to stick with mod_dav_svn).
>
> How did you manage permissions using svnserver? You mentioned a group
> which you gave read/write access for the file. Did you made
> svnserve-deamon member of thet group or did something else? I thought
> of lock files rep-cache.db which may be not created during
> insufficient permissions on the parent directory. But I don't know if
> SQLite works this way.
I ran the svnserver test as root, without any restrictions.
But I don't think it's a permission issue on the rep-cache.db file since I even tried giving it unrestricted read/write access to be sure that wasn't the case. Could other files be involved?
Re: "Couldn't open rep-cache database" (post commit FS processing)
Posted by Aleksandr Sidorenko <as...@espeo.com>.
On 2011-11-14, at 11:38 , Daniel Shahaf wrote:
> Aleksandr Sidorenko wrote on Mon, Nov 14, 2011 at 11:06:49 -0500:
>> Hi everyone,
>>
>> I've searched the mailing list archive for this error, but results were pretty limited. I also haven't found a fix elsewhere on the web.
>>
>> The exact error I am getting upon a commit is:
>>
>
> How reproducible is it? How often do you get this error?
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=3506
The error occurs every time, for either existing checkouts or new ones made after the server update, in any one of our repositories.
Since posting the question, I tried using "svnserve" instead of Apache (the mod_dav_svn module), and the error does NOT occur in this case (we would still prefer to stick with mod_dav_svn).
Re: "Couldn't open rep-cache database" (post commit FS processing)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Aleksandr Sidorenko wrote on Mon, Nov 14, 2011 at 11:06:49 -0500:
> Hi everyone,
>
> I've searched the mailing list archive for this error, but results were pretty limited. I also haven't found a fix elsewhere on the web.
>
> The exact error I am getting upon a commit is:
>
How reproducible is it? How often do you get this error?
http://subversion.tigris.org/issues/show_bug.cgi?id=3506
> Sending xxxxxxx
> Transmitting file data .
> Committed revision xxxxxxx.
>
> Warning: post commit FS processing had error:
> Couldn't open rep-cache database
>
> The commit itself is done properly. On the SVN server, the permissions on db/rep-cache.db are correct (read/writeable by the correct user/group used by the Apache web server).
>
> Of note, this error started right after we updated the server from 1.6.12 to 1.7.1.
>
> Any help would be greatly appreciated!
>
>
> Aleksandr Sidorenko
> Administrateur systèmes/réseaux • System/Network Administrator
>
> Espeo Inc.
> 2000, ave McGill College, bureau 230
> Montréal, Québec (H3A 3H3)
> www.espeo.com
>
> asidorenko@espeo.com
> 514-905-1268 #234
>