Re: [Sks-devel] Raising Sys.Break -- PTree may be corrupted: Failure("add_to_node: attempt to reinsert element into prefix tree")

[John Clizbe]

Christoph Anton Mitterer wrote:
> Hi.
> 
> As mentioned previously I'm in the process of migrating/re-installing my
> SKS instance at much better machine...
> 
> I run SKS 1.1.3 from Debian sid (which has BDB 5.1, IIRC).
> 
> Just for trying, I dumped the keydb from my old server, and made a full
> build on the new one (which worked fine, i.e. no errors[0] during that
> were shown).
> 
> Anyway, when I now start sks, then the db process seems to run fine:
> 2013-07-31 05:16:11 Opening KeyDB database
> 2013-07-31 05:16:11 Calculating DB stats
> 2013-07-31 05:16:15 Done calculating DB stats
> 2013-07-31 05:16:15 Database opened
> 2013-07-31 05:16:15 Applied filters: yminsky.dedup, yminsky.merge
> 2013-07-31 05:16:15 Sending LogResp size 62
> 2013-07-31 06:16:15 Checkpointing database
> 2013-07-31 06:16:15 Checkpointing complete
> 2013-07-31 07:16:15 Checkpointing database
> 2013-07-31 07:16:15 Checkpointing complete
> 
> 
> But the recon process just dies a few seconds after it started:
> 2013-07-31 05:16:11 sks_recon, SKS version 1.1.3
> 2013-07-31 05:16:11 Copyright Yaron Minsky 2002-2003
> 2013-07-31 05:16:11 Licensed under GPL.  See COPYING file for details
> 2013-07-31 05:16:11 Opening PTree database
> 2013-07-31 05:16:11 Setting up PTree data structure
> 2013-07-31 05:16:11 PTree setup complete
> 2013-07-31 05:16:15 Raising Sys.Break -- PTree may be corrupted:
> Failure("add_to_node: attempt to reinsert element into prefix tree")
> 2013-07-31 05:16:15 DB closed
> 
> (again, this is a fresh install).
> 
> 
> sks cleandb didn't help.
> 
It won't. It does its magic after build and before pbuild.

The BIG error I see is "Sending LogResp size 62" as soon as the key DB is
opened. That message should normally only appear at the end of any key db
updates during a recon session. See logs below

db.log:
2013-07-31 09:41:27 0 potential merges found for keyid 6038A69D
2013-07-31 09:41:27 1 updates found before filtering
2013-07-31 09:41:27 Applying 1 changes
2013-07-31 09:41:27 Adding hash 0BAA93183B7D134DA052C56C48BC4E4C
2013-07-31 09:41:27 Sending LogResp size 1

recon.log:
2013-07-31 09:41:17 Beginning recon as server, client: <ADDR_INET
[74.50.54.66]:47195>
2013-07-31 09:41:17 Joining reconciliation
2013-07-31 09:41:17 Reconciliation complete
2013-07-31 09:41:17 1 hashes recovered from <ADDR_INET [74.50.54.66]:11371>
2013-07-31 09:41:17     0BAA93183B7D134DA052C56C48BC4E4C
2013-07-31 09:41:17 Disabling gossip
2013-07-31 09:41:27 Requesting 1 missing keys from <ADDR_INET
[74.50.54.66]:11371>, starting with 0BAA93183B7D134DA052C56C48BC4E4C
2013-07-31 09:41:27 1 keys received
2013-07-31 09:41:27 setting synctime to 1375281687.478757
2013-07-31 09:41:27 Added 1 hash-updates. Caught up to 1375281687.478757
2013-07-31 09:41:27 Enabling gossip

09:41:27 recon requests and receives the missing key and passes it to db which
processes the key and sends the LogResp message. recon updates the sync time
and logs the hash update


It /looks/ like sks_db is trying to finish a transaction the sks_recon has  no
idea about.  I would suggest running db_recover to roll-back any uncommitted
transactions and then db_checkpoint on each of the database directories and
then try running sks again.

If recon still dies on startup I would delete PTree and run sks pbuild again.

-John
-- 
John P. Clizbe                      Inet: John (a) Gingerbear DAWT net
SKS/Enigmail/PGP-EKP                  or: John ( @ ) Enigmail DAWT net
FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
     mailto:address@hidden

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"

signature.asc
Description: OpenPGP digital signature