Important!
My tech articles—especially Linux ones—are some of the most-viewed on The Z-Issue. If this one has helped you, please consider a small donation to The Parker Fund by using the top widget at the right. Thanks!Yet again, I had troubles with restarting amavisd after some package updates. You can see about the other problems that I’ve had with the application in these two previous blog posts: missing SpamAssassin rules causing amavis to fail and start-up failures due to a missing Perl IPv6 module.
This time, the problem was related to the backend database used for Bayes filtering within SpamAssassin, although it wasn’t readily clear what the problem was. After updating SpamAssassin, I saw the following message from Portage (Gentoo‘s package manager):
* You need to configure your database to be able to use Bayes filter
* with database backend, otherwise it will still use (and need) the
* Berkeley DB support.
* Look at the sql/README.bayes file in the documentation directory
* for how to configure it.
At first, I thought that there was a problem with my MariaDB installation, but then I remembered that I’m currently still using BerkeleyDB (BDB) for SpamAssassin.
After trying to stop and restart amavisd, zapping the configuration (which was a problem mentioned in one of my previous posts), manually killing the running amavisd processes, and a few other things, I was still left with a configuration that would cause amavisd to fail on startup:
* Starting amavisd-new ...
Problem in Amavis::DB or Amavis::DB::SNMP code:
BerkeleyDB needs compatible versions of libdb & db.h
you have db.h version 6.0.30 and libdb version 6.0.35
Compilation failed in require at (eval 93) line 20.
BEGIN failed--compilation aborted at (eval 93) line 20. [ !! ]
* ERROR: amavisd failed to start
Out of sheer desperation, I attempted what seemed to be an unlikely fix by recompiling BerkleyDB (via emerge -v dev-perl/BerkeleyDB). Lo and behold, amavis decided to start after that recompilation! It’s a bit strange to me that the standard tools like revdep-rebuild and emerge @preserved-rebuild didn’t catch this problem.
In any case, third time is a charm with amavisd. Hopefully there won’t be any further problems when attempting to reload or restart it.
Cheers,
Zach
4 comments
Skip to comment form
Did you try perl-cleaner?
Author
I did not try perl-cleaner since there weren’t any direct updates to Perl, but I probably should have. Good point.
Cheers,
Zach
You can be sure that sys-libs/db does synchronize lib and header version. Versions 6.0.30 and 6.0.35 are supposed to be compatible as well. What must be going on here is that dev-perl/BerkeleyDB in its compilation somehow records the version of either the header or the library (probably the header) it was compiled against. The dependency rebuild systems are focussed on binary incompatibilities and cannot really handle this kind of weird behaviour.
Looking at it, it may be that the pearl header for db.h was not regenerated.
Author
That’s a very good point, Paul, and you’re right that revdep-rebuild wouldn’t catch something like lib and header version inconsistencies.
Cheers,
Zach