[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.
signature.asc
Description: OpenPGP digital signature