following up from a rather old thread...
On Thu 2015-04-30 14:52:48 -0400, Tobias Mueller wrote:
> On Fr, 2015-04-10 at 17:18 -0400, Daniel Kahn Gillmor wrote:
>> I consider this a bug in SKS, if it can overconsume RAM on the basis
>> of one misbehaving or rejecting peer.
>>
>> the implication is
Hi.
On Fr, 2015-04-10 at 17:18 -0400, Daniel Kahn Gillmor wrote:
> I consider this a bug in SKS, if it can overconsume RAM on the basis
> of one misbehaving or rejecting peer.
>
> the implication is that a network attacker can force any SKS server
> into this state.
>
> Have you filed a bug repo
On Fri 2015-04-10 03:32:20 -0400, Kiss Gabor (Bitman) wrote:
>> sks 1.1.5+ requires round about 300MB in main memory on key.cccmz.de and
>> key.ip6.li. May be there is a problem, when haproxy is used in tcp mode to
>> proxy port 11370. key.ip6.li did not have problems, but a test system has
>> als
> > > > Once you do it the log will have the peer you are connected to when
> > > > the Out of memory happens.
> > >
> > > It is cccmz.de. All "Out of memory" messages are in this context:
> >
> > > Christian!
> > > I cease peering for a few days to see if extreme memory consumption
> > > was real
On Thu, 19 Mar 2015, Kiss Gabor (Bitman) wrote:
> > > Once you do it the log will have the peer you are connected to when
> > > the Out of memory happens.
> >
> > It is cccmz.de. All "Out of memory" messages are in this context:
>
> > Christian!
> > I cease peering for a few days to see if extrem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 18 Mar 2015, Kiss Gabor (Bitman) wrote:
> > Once you do it the log will have the peer you are connected to when
> > the Out of memory happens.
>
> It is cccmz.de. All "Out of memory" messages are in this context:
> Christian!
> I cease peeri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Once you do it the log will have the peer you are connected to when
> the Out of memory happens.
It is cccmz.de. All "Out of memory" messages are in this context:
2015-03-18 06:15:51 Recon partner:
2015-03-18 06:15:51 Initiating reconciliation
201
> > I can see " error in callback.: Out of memory"
> > messages and a certain amount of "Reconciliation attempt from xxx
> > while gossip disabled. Ignoring."
> >
> > I don't know if the later may cause the memory consumption.
> > Now I disable them at IP level.
> > Then let's see what happens...
>
Kiss Gabor (Bitman) wrote:
>
> I can see " error in callback.: Out of memory"
> messages and a certain amount of "Reconciliation attempt from xxx
> while gossip disabled. Ignoring."
>
> I don't know if the later may cause the memory consumption.
> Now I disable them at IP level.
> Then let's see wh
> Peer misbehaviour can be other things than excessive input. A better
> place to look for hints is recon.log. Remember to raise recon
> debuglevel.
I can see " error in callback.: Out of memory"
messages and a certain amount of "Reconciliation attempt from xxx
while gossip disabled. Ignoring."
I
Gabor Kiss:
>> http://bakacsin.ki.iif.hu/~kissg/tmp/memory-day.png
>
>> May be hunt for misbehaving peers.
>
> Flow analysis shows almost no traffic on port 11370
> yesterday between 21:20 and 22:20 CET when memory consumption increased.
> (937 bytes in 14 packets.)
> So it is due other than exces
On 14.03.2015 01:47, Kiss Gabor (Bitman) wrote:
> > for my server, i have
> >
> > # max cache DB
> > cache: 80
>
> I have no such settings.
> sksconf is unchanged since Dec 17 2013.
>
> Now I add this entry. Then I listen and wait. :-)
At first sight memory footprint of sks recon is drasticall
> > At first sight memory footprint of sks recon is drastically reduced.
>
> ... but after a few hours suddenly it grew again.
> http://bakacsin.ki.iif.hu/~kissg/tmp/memory-day.png
> May be hunt for misbehaving peers.
Flow analysis shows almost no traffic on port 11370
yesterday between 21:20 an
> > > for my server, i have
> > >
> > > # max cache DB
> > > cache: 80
> >
> > I have no such settings.
> > sksconf is unchanged since Dec 17 2013.
> >
> > Now I add this entry. Then I listen and wait. :-)
>
> At first sight memory footprint of sks recon is drastically reduced.
... but after
> > for my server, i have
> >
> > # max cache DB
> > cache: 80
>
> I have no such settings.
> sksconf is unchanged since Dec 17 2013.
>
> Now I add this entry. Then I listen and wait. :-)
At first sight memory footprint of sks recon is drastically reduced.
Thanks again.
Gabor
--
"Wenn ist d
Dear Robert,
> Did you check the cache value in /etc/sks/sksconf.
>
> for my server, i have
>
> # max cache DB
> cache: 80
I have no such settings.
sksconf is unchanged since Dec 17 2013.
Now I add this entry. Then I listen and wait. :-)
Thanks.
Gabor
--
A mug of beer, please. Shaken, not
hi ,
Did you check the cache value in /etc/sks/sksconf.
for my server, i have
# max cache DB
cache: 80
regards
robert
===
Le 12/03/2015 16:19, Gabor Kiss a écrit :
>> Last Friday I reorganized disk partitions used by SKS.
>> At first sight it was all right but now I found, that
>> recon proce
Gabor Kiss writes:
> Any idea?
May be hunt for misbehaving peers.
--
Kim Minh
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03/12/2015 04:19 PM, Gabor Kiss wrote:
>> Last Friday I reorganized disk partitions used by SKS. At first
>> sight it was all right but now I found, that recon process
>> consumes the whole memory:
>
>> I already restarted it yesterday but today
> Last Friday I reorganized disk partitions used by SKS.
> At first sight it was all right but now I found, that
> recon process consumes the whole memory:
> I already restarted it yesterday but today I'm out of memory again.
> My system:
> Stock Debian wheezy. Package version is 1.1.5-1~bpo70+1.
On 2010-02-02 at 01:19 +0100, Arnold wrote:
> If it is not in the number of peers, then what can I do further to make it
> sync more quickly?
Do the recon logs contain anything to suggest a cause for not fetching
all keys? What about if you bump up the debug level?
-Phil
pgpjInGigw0WP.pgp
Desc
* Kim Minh Kaplan [2010-02-02 14:28]:
> Sebastian Wiesinger wrote:
>
> > 2010-02-01 07:17:31 Requesting 100 missing keys from > [79.18.143.39]:11371>, starting with 0058751DD7011D0C0A2FB5CB04F462C1
> > 2010-02-01 07:18:33 Error getting missing keys: End_of_file
>
> This is probably the source o
Sebastian Wiesinger wrote:
> 2010-02-01 07:17:31 Requesting 100 missing keys from [79.18.143.39]:11371>, starting with 0058751DD7011D0C0A2FB5CB04F462C1
> 2010-02-01 07:18:33 Error getting missing keys: End_of_file
This is probably the source of your problem.
--
Kim Minh.
http://www.kim-minh.com
* Phil Pennock [2010-02-01 20:24]:
> On 2010-02-01 at 11:47 +0100, Sebastian Wiesinger wrote:
> > Hello,
> >
> > my sks recon server is using waaay to much memory:
> >
> > lita:~# ps auxww | fgrep sks
> > 126 4317 0.0 1.1 70584 47372 ?S 2009 35:20
> > /usr/sbin/sks db
> >
Hi,
on 2010-02-02 01:19 Arnold wrote the following:
> Hi,
>
> On 02-02-10 00:15, Phil Pennock wrote:
>> On 2010-02-01 at 16:25 -0500, Daniel Kahn Gillmor wrote:
>>> Are you suggesting that if a single peer was to, say, flush its DB and
>>> re-connect, it could trigger this memory consumption on a
Hi,
On 02-02-10 00:15, Phil Pennock wrote:
> On 2010-02-01 at 16:25 -0500, Daniel Kahn Gillmor wrote:
>> Are you suggesting that if a single peer was to, say, flush its DB and
>> re-connect, it could trigger this memory consumption on all/any of its
>> peers? Would the memory consumption increase
On 2010-02-01 at 16:25 -0500, Daniel Kahn Gillmor wrote:
> Are you suggesting that if a single peer was to, say, flush its DB and
> re-connect, it could trigger this memory consumption on all/any of its
> peers? Would the memory consumption increase proportionally to the
> number of peers which di
On 02/01/2010 02:22 PM, Phil Pennock wrote:
> On 2010-02-01 at 11:47 +0100, Sebastian Wiesinger wrote:
>> my sks recon server is using waaay to much memory:
>>
>> lita:~# ps auxww | fgrep sks
>> 126 4317 0.0 1.1 70584 47372 ?S 2009 35:20
>> /usr/sbin/sks db
>> 126 4320
Phil Pennock wrote:
> On 2010-02-01 at 11:47 +0100, Sebastian Wiesinger wrote:
>> Hello,
>>
>> my sks recon server is using waaay to much memory:
>>
>> lita:~# ps auxww | fgrep sks
>> 126 4317 0.0 1.1 70584 47372 ?S 2009 35:20
>> /usr/sbin/sks db
>> 126 4320 0.0 40.4
On 2010-02-01 at 11:47 +0100, Sebastian Wiesinger wrote:
> Hello,
>
> my sks recon server is using waaay to much memory:
>
> lita:~# ps auxww | fgrep sks
> 126 4317 0.0 1.1 70584 47372 ?S 2009 35:20
> /usr/sbin/sks db
> 126 4320 0.0 40.4 3459124 1629992 ? S 2
30 matches
Mail list logo
