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:pgp-public-k...@gingerbear.net?subject=HELP 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
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel