DB_LOGC->get: LSN 44/32711: invalid log record header after db-recover

[Matthias Andree]

Chris Wilkes <cwilkes-bf at ladro.com> writes:

> On Sat, Jan 15, 2005 at 03:37:41AM +0100, Matthias Andree wrote:
>> Chris Wilkes <cwilkes-bf at ladro.com> writes:
>> 
>> > Which I run and it gives me the same message:
>> >   $ bogoutil -v --db-recover "/home/vmail/maildirs/cwilkes/.bogofilter/"
>> >   DB_LOGC->get: LSN 44/32711: invalid log record header
>> >   ...
>> 
>> Have log files been removed?
>
> Yes, I had some problems with bf_compact and went through some of the
> steps outlined here:
>   http://article.gmane.org/gmane.mail.bogofilter.general/9090
> I believe I ended up copying the files under a bf_compact.$$ directory,
> which inclues the log.* __db.* and wordlist.db files.

Yup. The order of log.* vs. *.db is critical, see below.

>> What log files are in place?
>
> There's a whole bunch of old log.* files from Jan 9th, the only recent
> ones being:
>
> $ ls -ltr | tail -5
> -rw-rw-r--  1 vmail vmail       48 Jan  9 10:07 DB_CONFIG
> -rw-rw-r--  1 vmail vmail   984132 Jan 10 05:45 log.0000000043
> -rw-rw-r--  1 vmail vmail     1024 Jan 14 17:21 lockfile-p
> -rw-rw-r--  1 vmail vmail  8908800 Jan 14 17:50 wordlist.db-BACKUP
> -rw-rw-r--  1 vmail vmail  8953856 Jan 14 18:00 wordlist.db

If the wordlist.db file is newer than the log file (and it is), the
database environment is corrupt, and that explains your invalid log
record header. For copying environments, proper order is required, first
the *.db files, then the log.* files. bf_copy gets this right.

If db_verify wordlist.db does not complain, you can try to rescue it as
suggested in my previous mail. You've written this has worked for you,
fine.

>> Can you tar up the whole directory (with your mail system quiet) and
>> play around a bit, including catastrophic recovery?
>
> What is the catastropic recovery option?  I only know about dumping the
> database tokens to stdout and rebuilding from that and the db_dump
> method as described in the FAQ.

bogoutil --db-recover-harder "DIRECTORY". If not all the log files are
there, it will fail though.

>> Alternatively, dump your database to a temporary file, then remove all
>> of the the __db.* and log.* files, the *.db file, then run db_load with
>> the permanent filename.
>
> That did the trick!  Thanks.

You're welcome.

-- 
Matthias Andree