Re: [Sks-devel] Problems with sks_build

[Christopher Kleen]

Dear Kristian Fiskerstrand!


Thank you for your answer.
I have forgotten, that I have to set the ulimits again after opening a screen session. So the "main" session had unlimited sizes but the screen session did not.

But this does not help me with my problem. Using a higher -n flag does not affect the result:
> brk(0x3e227000)                         = 0x3e227000
> brk(0x3e320000)                         = 0x3e320000
> brk(0x3e419000)                         = 0x3e419000
> brk(0x3e512000)                         = 0x3e512000
> futex(0x2b2640f02358, FUTEX_WAIT, 2, NULL

Waiting many hours for a wonder with the FUTEX_WAIT did not help.
I have reproduced the error at
my home desktop system using Linux Mint 12 64 bit, 3.0.0-12, SKS v1.1.1+dpkgv3-7
and a second server using Debian Lenny, 32 bit, 2.6.32-5, SKS v1.1.1+dpkgv3-7.
And I have an idea, that it does not work with a third server.

Because many systems with the same SKS package did not work, I had the idea to try an older version: v1.1.0-4
And what happens? -> It works!
The strace provides many pwrites and the DB folder, which has stopped at 77MB yet, rises and rises. And finishes.

So the problem was:
The version of SKS is just broken.
And I thought that Debian only lets in tested packages. But this is not the first broken package, I got from the Debian repo. E.g. the ejabberd is not able to communicate with other servers. With an earlier version it works.

Whatever. I have my database and will now copy it to my three other servers in my pool.
Next step: Finding gossip peers.


Yours,
Christopher



Am 20.03.2012 09:15, schrieb Kristian Fiskerstrand:

On 20.03.2012 02:30, Christopher Kleen wrote:

> Hi @ *. !


> I have problems while building a database using a dump. If I use
> the sks build utility the process always ends at the following
> point, the size of the DB folder is always 77MB andthe process is
> just stopable with the kill signal.
...


getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
>> rt_sigaction(SIGSEGV, {SIG_DFL, [], SA_RESTORER, 0x7f8f3b024030},
>> NULL,
> 8) = 0
>> rt_sigreturn(0xb) = 881714904 --- SIGSEGV (Segmentation fault) @
>> 0 (0) --- +++ killed by SIGSEGV +++ Segmentation fault


...

What is the stack size (presumably 8192 from output above)? (ulimit
-s) , quite typical to run out on a x64 system, so what happens if you
set this to unlimited and then try to run the process again?

--
----------------------------
Kristian Fiskerstrand
http://www.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Corruptissima re publica plurimæ leges
The greater the degeneration of the republic, the more of its laws
----------------------------
This email was digitally signed using the OpenPGP
standard. If you want to read more about this
The book: Sending Emails - The Safe Way: An
introduction to OpenPGP security is now
available in both Amazon Kindle and Paperback
format at
http://www.amazon.com/dp/B006RSG1S4/
----------------------------
Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/

>
>
> _______________________________________________
> Sks-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/sks-devel

--
Christopher Kleen
www.kleen.ch

PGP/GPG-Schlüssel: http://gpg.kleen.ch
S/MIME-Zertifikat: http://smime.kleen.ch