[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sks-devel] Excessive use of /var/lib/sks/DB/log.*
From: |
John Zaitseff |
Subject: |
Re: [Sks-devel] Excessive use of /var/lib/sks/DB/log.* |
Date: |
Sat, 9 Feb 2019 10:35:29 +1100 |
User-agent: |
NeoMutt/20170113 (1.7.2) |
Hi, all,
> In fact... I think that The Debian Way™ would be to have [the
> DB_CONFIG file] in /etc/sks, with a message on top clearly stating
> it should be linked from /var/lib/sks/DB (as we Debian people are
> often too lazy to look up configuration details in our software
> and expect everything to be in /etc) 😉
That is indeed how I set up my own system: /etc/sks/DB_CONFIG is the
actual config file, and /var/lib/sks/DB/DB_CONFIG and
/var/lib/sks/PTree/DB_CONFIG are symlinks to it.
> > If you're using a debian system, please compare
> > /usr/share/doc/sks/sampleConfig/DB_CONFIG with
> > /var/lib/sks/DB/DB_CONFIG
I overwrote my DB_CONFIG file back in September 2018. I changed
set_lock_timeout 1000
set_txn_timeout 1000
to
set_lock_timeout 10000000
set_txn_timeout 5000000
I did not notice any negative effects, but, by the same token, I was
still getting "add_keys_merge failed: Eventloop.SigAlarm" and "Key
addition failed: Eventloop.SigAlarm" in my log files. Changing
/etc/sks/sksconf to include the following lines has completely
stopped those events from occurring (I made the change five days
ago):
pagesize: 32
ptree_pagesize: 16
command_timeout: 600
max_recover: 150
I fear, however, that increasing the timeouts simply pushes the
problem slightly further down the track...
Yours truly,
John Zaitseff
--
John Zaitseff ,--_|\ The ZAP Group
Telephone: +61 2 9643 7737 / \ Sydney, Australia
Email: address@hidden \_,--._* https://www.zap.org.au/
v