This is a known issue to the SKS developers. The original DB pagesizes were not optimal. As bdb takes out a lock(mutex) per page, the entire pool may be exhausted when creating the database.
The first part of the working around this is to put reasonable pagesize values into sksconf to override the defaults of 2K for key and 512 for ptree # bdb's db_tune program suggests a pagesize of 65536 for [K]DB/key. In practice # this caused page deadlocks. I found 8K (16) and 16K (32) to be better values pagesize: 16 # # The tuner recommended 4096 (8) for the pagesize for PTree/ptree. I have had # very good results with 8196 ptree_pagesize: 16 Add values for pagesize and ptree_pagesize to sksconf and try building again In the SKS source, there is a sample DB_CONFIG file of tunable bdb parameters in the sampleConfig directory. Copy this file into the [K]DB and PTree directories. Then run db_recover to remove the old environment. I believe for debian the commands are: cd /var/lib/sks db_recover -h DB db_recover -h PTree Verify the database directories are owned by the sks user and sks should operate fine. SKS 1.1.4 introduces a couple changes to help alleviate this problem in the future: per table pagesize values for sksconf and the ability to utilize a DB_CONFIG file at database creation time. -- 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