You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Marinus Damm <ma...@jivesoftware.com> on 2006/11/29 17:04:02 UTC
svnsync sync fails partway through with "SSL negotiation failed: Cannot allocate memory"
Trying to go from a svn 1.4.2 source to a 1.3.2 destination.
a. Created a new empty 1.4.2 source repository, svnadmin load'ed a
3.9GB dump file into it.
b. Created a new empty 1.3.2 destination repository on another host.
c. svnsync init https://dest.example.com/svn2/repos file:///local/
svn/repos <-- works fine
d. svnsync sync https://dest.example.com/svn2/repos <-- fails after
several hours
The sync gets to around rev 15000 and then dies; command line error
message is:
...
Copied properties for revision 15540.
Committed revision 15541.
Copied properties for revision 15541.
svnsync: OPTIONS request failed on '/svn2/repos'
svnsync: OPTIONS of '/svn2/repos': SSL negotiation failed: Cannot
allocate memory (https://dest.example.com)
Both O.S.'s are CentOS 4 (clone of RedHat Enterprise Linux 4).
Subversion was built on the local machine in both cases.
The destination machine has Apache 2.0.52 w/ same version of mod_ssl.
I'm not sure where to begin looking for the problem; is the error
message passed out of svnsync from the destination machine? Or is
svnsync (and neon I guess) on the source machine complaining?
Any suggestions to relieve the condition? This will be a one-time
sync as part of our mirroring setup, so subsequent svnsync's should
be much smaller than this initial one. The sync is roughly 40% done
(both in terms of rev#s and size) when it dies.
Marinus Damm
Re: svnsync sync fails partway through with "SSL negotiation failed: Cannot allocate memory"
Posted by Marinus Damm <ma...@jivesoftware.com>.
Thanks for the insight.
I laughed out loud when I read your sublime suggestion to restart the
sync. That hadn't occurred to me. (sidebar: I love atomic actions)
After clearing the svn:sync-lock property from the destination
repository, I restarted the sync and it's humming along.
Marinus Damm
email: marinus@jivesoftware.com
phone: 503-972-7501
On Nov 29, 2006, at 9:26 AM, Erik Huelsmann wrote:
> On 11/29/06, Marinus Damm <ma...@jivesoftware.com> wrote:
>>
>> Trying to go from a svn 1.4.2 source to a 1.3.2 destination.
>>
>> a. Created a new empty 1.4.2 source repository, svnadmin load'ed a
>> 3.9GB
>> dump file into it.
>> b. Created a new empty 1.3.2 destination repository on another host.
>> c. svnsync init https://dest.example.com/svn2/repos
>> file:///local/svn/repos <-- works fine
>> d. svnsync sync https://dest.example.com/svn2/repos <--
>> fails after several hours
>>
>> The sync gets to around rev 15000 and then dies; command line
>> error message
>> is:
>>
>> ...
>> Copied properties for revision 15540.
>> Committed revision 15541.
>> Copied properties for revision 15541.
>> svnsync: OPTIONS request failed on '/svn2/repos'
>> svnsync: OPTIONS of '/svn2/repos': SSL negotiation failed: Cannot
>> allocate
>> memory (https://dest.example.com)
>
> As far as I can see, that's a client side error, meaning that this is
> a problem with Neon not being able to allocate more memory, or openssl
> (against which neon is linked for SSL support).
>
> Maybe Neon or svnsync forgets to deallocate some resource? It would be
> great if you or someone else could try to find out. (How? Using
> valgrind or pool-debugging?)
>
>> Both O.S.'s are CentOS 4 (clone of RedHat Enterprise Linux 4).
>> Subversion was built on the local machine in both cases.
>
>> I'm not sure where to begin looking for the problem; is the error
>> message
>> passed out of svnsync from the destination machine? Or is svnsync
>> (and neon
>> I guess) on the source machine complaining?
>
> It's the machine on which svnsync is running.
>
>> Any suggestions to relieve the condition? This will be a one-time
>> sync as
>> part of our mirroring setup, so subsequent svnsync's should be
>> much smaller
>> than this initial one. The sync is roughly 40% done (both in terms
>> of rev#s
>> and size) when it dies.
>
> I think it's safe to restart from where it left off. Does that work?
>
> bye,
>
> Erik.
Re: svnsync sync fails partway through with "SSL negotiation failed: Cannot allocate memory"
Posted by Erik Huelsmann <eh...@gmail.com>.
On 11/29/06, Marinus Damm <ma...@jivesoftware.com> wrote:
>
> Trying to go from a svn 1.4.2 source to a 1.3.2 destination.
>
> a. Created a new empty 1.4.2 source repository, svnadmin load'ed a 3.9GB
> dump file into it.
> b. Created a new empty 1.3.2 destination repository on another host.
> c. svnsync init https://dest.example.com/svn2/repos
> file:///local/svn/repos <-- works fine
> d. svnsync sync https://dest.example.com/svn2/repos <--
> fails after several hours
>
> The sync gets to around rev 15000 and then dies; command line error message
> is:
>
> ...
> Copied properties for revision 15540.
> Committed revision 15541.
> Copied properties for revision 15541.
> svnsync: OPTIONS request failed on '/svn2/repos'
> svnsync: OPTIONS of '/svn2/repos': SSL negotiation failed: Cannot allocate
> memory (https://dest.example.com)
As far as I can see, that's a client side error, meaning that this is
a problem with Neon not being able to allocate more memory, or openssl
(against which neon is linked for SSL support).
Maybe Neon or svnsync forgets to deallocate some resource? It would be
great if you or someone else could try to find out. (How? Using
valgrind or pool-debugging?)
> Both O.S.'s are CentOS 4 (clone of RedHat Enterprise Linux 4).
> Subversion was built on the local machine in both cases.
> I'm not sure where to begin looking for the problem; is the error message
> passed out of svnsync from the destination machine? Or is svnsync (and neon
> I guess) on the source machine complaining?
It's the machine on which svnsync is running.
> Any suggestions to relieve the condition? This will be a one-time sync as
> part of our mirroring setup, so subsequent svnsync's should be much smaller
> than this initial one. The sync is roughly 40% done (both in terms of rev#s
> and size) when it dies.
I think it's safe to restart from where it left off. Does that work?
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org