[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sks-devel] Peering Issues - High IO ending with Eventloop.SigAlarm
From: |
Kim Minh Kaplan |
Subject: |
Re: [Sks-devel] Peering Issues - High IO ending with Eventloop.SigAlarm always occur with 1 peer |
Date: |
Thu, 13 Dec 2018 16:41:19 +0000 |
Moritz Wirth wrote:
>
> Hi,
>
> this issue already known for several months now - see [0], [1].
>
> The keys used for this are very large (around 30-60MB). Syncing them takes
> some bandwith and indexing/writing them to the disk consumes a lot of CPU and
> I/O resources. If the addition to the database fails, the key is added again
> when another peer synchronizes it, causing the same load (which results in
> the large I/O spikes that you see).
>
> SKS is single threaded and therefore, any other action is blocked while the
> key addition takes place. This is also known for years and the fact that it
> can be easily used for attacks is ignored.
>
> If I remember correctly, the behaviour above is intended and therefore, I
> would not expect any fixes in the next months. There have been some fixes
> which exclude some of the bad keys [2] (which might be included in the
> ubuntu/debian sks packages so this may be why it stopped over the last
> months), however this only works as long as nobody generates and uploads a
> new key.
>
> Best Regards,
>
> Moritz
>
> [0]:
> https://bitbucket.org/skskeyserver/sks-keyserver/issues/61/key-addition-failed-blocks-web-interface
> [1]:
> https://bitbucket.org/skskeyserver/sks-keyserver/issues/60/denial-of-service-via-large-uid-packets
> [2]: https://lists.nongnu.org/archive/html/sks-devel/2018-07/msg00053.html
Another solution is to tune settings so that the key is downloaded and saved.
https://lists.nongnu.org/archive/html/sks-devel/2018-06/msg00072.html