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

[Matthias Andree]

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

Oops.

I have little experience with this kind of problem.

Have log files been removed? What log files are in place?
Can you play a bit with db_stat to see if it prints useful data related
to this problem?

> db_verify says that the wordlist is okay:
>   $ cd $BOGOFILTER_DIR
>   $ db_verify wordlist.db
>   $ echo $?
>   0
>   $ db_dump -r wordlist.db | db_load wordlist.new
>   $ echo $?
>   0
> So it looks like the wordlist.new should be fine, but:
>   $ mv wordlist.db wordlist.db-BACKUP && mv wordlist.new  wordlist.db
>   $ bogoutil -v --db-recover "."
>   DB_LOGC->get: LSN 44/32711: invalid log record header

Renaming or shuffling around database files with environment and logs in
place does not work.

>   ...
> gives me the same error as above.

Can you tar up the whole directory (with your mail system quiet) and
play around a bit, including catastrophic recovery?

Assuming you haven't had a crash, see if removing the environment
works. I doubt that, but I'd like some confirmation either way.

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.

>   $ bogoutil -d wordlist.db | bogoutil -l ./wordlist.new
>   DB_LOGC->get: LSN 44/32711: invalid log record header
>   ...
>   DB_LOGC->get: LSN 44/32711: invalid log record header 
>   ...
> gives me the same error, but for some reason it is repeated.

One from bogoutil -d, one from bogoutil -l. If there is a problem with
the environment, bogoutil -l will get trapped.

> # ls -l /usr/lib/libdb-4.2.so /lib/tls/i*86/libdb-4.2.so /lib/libdb-4.2.so
> -rwxr-xr-x  1 root root 843996 Sep 21 16:54 /lib/libdb-4.2.so

> -rwxr-xr-x  3 root root 845636 Sep 21 16:54 /lib/tls/i486/libdb-4.2.so
> -rwxr-xr-x  3 root root 845636 Sep 21 16:54 /lib/tls/i586/libdb-4.2.so
> -rwxr-xr-x  3 root root 845636 Sep 21 16:54 /lib/tls/i686/libdb-4.2.so

These three are hard links, actually only one version.

> lrwxrwxrwx  1 root root     22 Jan 12 22:43 /usr/lib/libdb-4.2.so -> ../../lib/libdb-4.2.so
>
>
> That last one is a little weird, why is the libdb-4.2.so under /lib just
> a little bit smaller than the other ones?  Probably is nothing.

The /lib/tls versions has "thread local storage" which the "plain /lib"

> What's odd about it is that even though a -v complains about the invalid
> log number the exit codes still correctly indicate spam or ham.

Yup, that's strange.

I still know too little about the Redhat/Fedora hacks and configuration
options to Berkeley DB and their impact on real applications.

-- 
Matthias Andree