sks-devel
[Top][All Lists]
Advanced

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

Re: [Sks-devel] Sync issues with sks 1.1.6


From: Steven Noonan
Subject: Re: [Sks-devel] Sync issues with sks 1.1.6
Date: Wed, 31 Aug 2016 04:47:10 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

Attempted doing a dump and rebuild of my database from that, but it didn't help
with this problem. Still sees those same two keys out of sync:

==> recon.log <==
2016-08-31 04:37:02 Added 1 hash-updates. Caught up to 1472643422.340101
2016-08-31 04:37:58 <recon as client> error in callback.: Sys_error("Connection 
reset by peer")
2016-08-31 04:38:56 2 hashes recovered from <ADDR_INET [184.105.143.180]:11371>
2016-08-31 04:38:56     3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:38:56     AA13C5E2197D1D97DF7061D30B954060
2016-08-31 04:38:56 Requesting 2 missing keys from <ADDR_INET 
[184.105.143.180]:11371>, starting with 3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:38:56 2 keys received

==> db.log <==
2016-08-31 04:38:56 Applying 0 changes

==> recon.log <==
2016-08-31 04:39:59 2 hashes recovered from <ADDR_INET [212.47.246.89]:11371>
2016-08-31 04:39:59     3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:39:59     AA13C5E2197D1D97DF7061D30B954060
2016-08-31 04:40:00 Requesting 2 missing keys from <ADDR_INET 
[212.47.246.89]:11371>, starting with 3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:40:01 2 keys received

==> db.log <==
2016-08-31 04:40:01 Applying 0 changes

==> recon.log <==
2016-08-31 04:40:54 4 hashes recovered from <ADDR_INET [192.110.255.57]:11371>
2016-08-31 04:40:54     3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:40:54     4C9895E31B8E52499BADB8F03A629E5F
2016-08-31 04:40:54     9C9A6B3836B3431317E1F507EBE02E69
2016-08-31 04:40:54     AA13C5E2197D1D97DF7061D30B954060
2016-08-31 04:41:04 Requesting 4 missing keys from <ADDR_INET 
[192.110.255.57]:11371>, starting with 3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:41:04 4 keys received

==> db.log <==
2016-08-31 04:41:04 Applying 0 changes

==> recon.log <==
2016-08-31 04:41:13 2 hashes recovered from <ADDR_INET [176.9.31.215]:11371>
2016-08-31 04:41:13     3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:41:13     AA13C5E2197D1D97DF7061D30B954060
2016-08-31 04:41:23 Requesting 2 missing keys from <ADDR_INET 
[176.9.31.215]:11371>, starting with 3C6042D474F66ED92D763E76BEAF6DE4
2016-08-31 04:41:23 2 keys received

==> db.log <==
2016-08-31 04:41:23 Applying 0 changes

Any idea what is happening here?

On 30/08/16 23:03, Steven Noonan wrote:
> I've noticed that SKS seems to be having trouble staying synced. I've seen
> it attempt to recover the same two hashes several times in a row, but
> apparently somehow not succeeding. Below is after a fresh restart of both
> the DB and recon services:
> 
> ==> db.log <==
> 2016-08-30 22:47:47 Calculating DB stats
> 2016-08-30 22:47:49 Done calculating DB stats
> 2016-08-30 22:47:49 Database opened
> 2016-08-30 22:47:49 Applied filters: yminsky.dedup, yminsky.merge
> 2016-08-30 22:52:38 Applying 4 changes
> 2016-08-30 22:52:38 Adding hash 5A43BA76C61920AD131BEB229F01CE77
> 2016-08-30 22:52:38 Adding hash 5E74523E56488B6FE65FAA3C584AAABF
> 2016-08-30 22:52:38 Adding hash 98CD7C824D3BEEC91B858BF4B53BE479
> 2016-08-30 22:52:38 Adding hash EEC18519F506D79394196B5F58A1A9F0
> 2016-08-30 22:52:39 Sending LogResp size 4
> 
> ==> recon.log <==
> 2016-08-30 22:52:37     5E74523E56488B6FE65FAA3C584AAABF
> 2016-08-30 22:52:37     98CD7C824D3BEEC91B858BF4B53BE479
> 2016-08-30 22:52:37     AA13C5E2197D1D97DF7061D30B954060
> 2016-08-30 22:52:37     EEC18519F506D79394196B5F58A1A9F0
> 2016-08-30 22:52:38 Requesting 6 missing keys from <ADDR_INET 
> [163.172.29.20]:11371>, starting with 3C6042D474F66ED92D763E76BEAF6DE4
> 2016-08-30 22:52:38 6 keys received
> 2016-08-30 22:52:39 Added 4 hash-updates. Caught up to 1472622758.953643
> 2016-08-30 22:53:57 2 hashes recovered from <ADDR_INET 
> [184.105.143.180]:11371>
> 2016-08-30 22:53:57     3C6042D474F66ED92D763E76BEAF6DE4
> 2016-08-30 22:53:57     AA13C5E2197D1D97DF7061D30B954060
> 2016-08-30 22:54:07 Requesting 2 missing keys from <ADDR_INET 
> [184.105.143.180]:11371>, starting with 3C6042D474F66ED92D763E76BEAF6DE4
> 2016-08-30 22:54:07 2 keys received
> 
> ==> db.log <==
> 2016-08-30 22:54:07 Applying 0 changes
> 
> ==> recon.log <==
> 2016-08-30 22:55:14 2 hashes recovered from <ADDR_INET [78.46.223.54]:11371>
> 2016-08-30 22:55:14     3C6042D474F66ED92D763E76BEAF6DE4
> 2016-08-30 22:55:14     AA13C5E2197D1D97DF7061D30B954060
> 2016-08-30 22:55:17 Reconciliation attempt from <ADDR_INET 
> [78.47.176.74]:51680> while gossip disabled. Ignoring.
> 2016-08-30 22:55:24 Requesting 2 missing keys from <ADDR_INET 
> [78.46.223.54]:11371>, starting with 3C6042D474F66ED92D763E76BEAF6DE4
> 2016-08-30 22:55:24 2 keys received
> 
> ==> db.log <==
> 2016-08-30 22:55:24 Applying 0 changes
> 
> ==> recon.log <==
> 2016-08-30 22:57:47 4 hashes recovered from <ADDR_INET [163.172.29.20]:11371>
> 2016-08-30 22:57:47     1411D6DD875ABB5E89B4CB389B3C3487
> 2016-08-30 22:57:47     3C6042D474F66ED92D763E76BEAF6DE4
> 2016-08-30 22:57:47     78C2581DB360C4EAD780866602AE2BFF
> 2016-08-30 22:57:47     AA13C5E2197D1D97DF7061D30B954060
> 2016-08-30 22:57:48 Requesting 4 missing keys from <ADDR_INET 
> [163.172.29.20]:11371>, starting with 1411D6DD875ABB5E89B4CB389B3C3487
> 2016-08-30 22:57:48 4 keys received
> 
> ==> db.log <==
> 2016-08-30 22:57:48 Applying 2 changes
> 2016-08-30 22:57:48 Adding hash 1411D6DD875ABB5E89B4CB389B3C3487
> 2016-08-30 22:57:48 Adding hash 78C2581DB360C4EAD780866602AE2BFF
> 2016-08-30 22:57:49 Sending LogResp size 2
> 
> ==> recon.log <==
> 2016-08-30 22:57:49 Added 2 hash-updates. Caught up to 1472623068.709972
> 
> For some reason the DB doesn't appear to want to add the hashes
> 3C6042D474F66ED92D763E76BEAF6DE4 and AA13C5E2197D1D97DF7061D30B954060.
> It's also mentioning "while gossip disabled" in the recon log, but I'm
> not sure I understand what conditions cause that to happen. I don't have
> a 'dontgossip' line in my sksconf or anything like that. 
> 


-- 
F8D5 F819 8DEB 0703 1565  1A90 7EAC B44B A7B3 0DB9
I am tycho (https://keybase.io/tycho) on keybase.


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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