Re: [Sks-devel] Debian SKS Upgrad Problem - Bdb.DBError

[John Clizbe]

 d
Ronny Wagner wrote:
> Hallo Tobias and John,
> 
> Server 01
> I do a rebuild from a keydump, but its very slowly (/usr/sbin/sks build
> /var/lib/sks/dump/*.pgp -n 2 -cache 100)

rebuilding kdb is not so great an idea as the problem was most likely in
PTree. running pbuild to build a new PTree is an option, but it just kicks the
can down the road a bit

side note; for build, I've found a good value of -n to be 6-7 times the amount
of GM of RAM available

> Server 02
> /var/lib/sks/DB/DB_CONFIG
> set_mp_mmapsize         268435456
> set_cachesize    0      134217728 1
> set_flags               DB_LOG_AUTOREMOVE
> set_lg_regionmax        1048576
> set_lg_max              104857600
> set_lg_bsize            2097152
> set_lk_detect           DB_LOCK_DEFAULT
> set_tmp_dir             /tmp
> set_lock_timeout        1000
> set_txn_timeout         1000
> mutex_set_max           65536
> 
> /var/lib/sks/PTree/
> No File in this directory
> 
> Can I copy the file from DB to PTree?

yes. you can copy the file from the KDB dir to the PTree dir.

After copying the file, run db_recover -h PTree to remover the old
environment. A new environment using the values in DB_CONFIG will be created
the next time SKS recon starts


if you continue to have problems with mutex exhaustion, try raising
mutex_set_max to 96K (983040 from the current 64K


-- 
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"