sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Sks-devel] How to resolve this cycle of `add_keys_merge failed: Eventlo


From: tiker
Subject: [Sks-devel] How to resolve this cycle of `add_keys_merge failed: Eventloop.SigAlarm` ?
Date: Wed, 20 Jun 2018 09:02:56 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

My assumption from what I've observed on my node is that there are at
least 2, possibly 3 versions (different hashes) of the 22mb key.

My node does the same thing everytime it recons with another node who
has a different hash of the 22mb key.

What I believe is happening is if my peer does not have a size limit
(8mb) set and I receive the entire 22mb key, my node then tries to merge
my 22mb key with the 22mb key received (attempting to create a 44mb
key).  The size of the new key seems to be an issue.

My node being a Raspberry Pi stops responding for about 7 - 8 minutes
when trying to merge the large keys.  The load on the Pi is all disk
related and this is when most of the .log files are created in the DB
directory.  A recent post to this list with the same issue shows it was
about a minute (from the time stamps) so I'm assuming there's something
in the code or DB that won't allow for a 44mb key.

I have thought about downloading the different hash versions of the key,
merging them together on my desktop and then quickly deleting the key
from my node and adding the 44mb key to it.  The problem is, all of my
peers would then be trying to grab 44mb (or possibly 66mb if there are 3
versions) from me which would probably make things worse for myself and
my peers (including you Paul).

So for now, I'm also waiting for some sort of solution to the problem.
I'm hoping someone is fixing the SKS code to prevent more keys like this
from being uplaoded first, then working on a way to remove this key.

Thanks.
Rob D


On Wed, 20 Jun 2018 09:56:51 +0100
Paul M Furley <address@hidden> wrote:

> Hi folks,
> 
> I've been following this bad key business since Friday when my server's 
> disk filled up with logs and self destructed.
> 
> Since then I've:
> 
> - Rebuilt the server from a dump
> - Added `set_flags DB_LOG_AUTOREMOVE` to /var/lib/sks/DB/DB_CONFIG
> - Increased nginx's `client_max_body_size` from 8m to 32m 
> (https://lists.nongnu.org/archive/html/sks-devel/2018-06/msg00016.html)
> - Add monitoring to syslog for `SigAlarm` and nginx logs for timeout errors
> - Restarted everything
> 
> 
> ... and I'm still in a cycle where something happens with recon that 
> causes the server to become unresponsive, then ultimately logs the 
> `Eventloop.SigAlarm` error into syslog. This is happening approximately 
> 9 times per hour.
> 
> During these periods any unfortunate client hitting my server in the 
> pool gets a long wait followed by an nginx gateway timeout :(
> 
> I'm also seeing about 800Mb traffic each hour, more than the usual ~250Mb.
> 
> Here's a paste with the logs from two occurrences:
> 
> https://pad.riseup.net/p/vAJwQhL8uu69
> 
> Can anyone suggest a remedy?
> 
> Kind regards,
> 
> Paul
> 
> 0xA999B7498D1A8DC473E53C92309F635DAD1B5517
> 
> 
> 


-- 


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]