On Fri 2019-02-08 16:48:16 -0600, Gunnar Wolf wrote:
> Hey dkg!
hi Gunnar! :)
> With hindsight, that was my mistake - When I rebuilt my server
> about a month ago (after a DB corruption), I decided to keep my
> installation and just delete /var/lib/sks/DB/*, rebuilding from
> dumps. Of course, I
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
Hey dkg!
> If you're using a debian system, please compare
> /usr/share/doc/sks/sampleConfig/DB_CONFIG with
> /var/lib/sks/DB/DB_CONFIG -- if your files differ, i'd be happy to help
> you figure out whether the problematic behavior you're seeing could be
> attributable to those differences.
>
>
On Wed 2019-02-06 20:27:28 -0800, Todd Fleisher wrote:
> This sounds like you are missing the recommended DB_CONFIG values to
> prevent your server from holding into those log files when an issue is
> encountered. As I recall, the fix is to start over from scratch and
> rebuild after first putting
This sounds like you are missing the recommended DB_CONFIG values to prevent
your server from holding into those log files when an issue is encountered. As
I recall, the fix is to start over from scratch and rebuild after first putting
that file in place. It is covered in the list archives and
Hello,
Since a couple of days ago, I have noticed an incredible growth in
space usage (so much it has killed my server twice, hitting partition
limits). Since February 3rd, I have over 4000 files with binary-only
contents (could find no meaningful information in them) called
/var/lib/sks/DB/log.
