sks-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]