Be careful with dspam and multi-arch

Do you use the Debian dspam packages, specifically with one of the database backends? Recently upgraded the packages? Does noone email you anymore?

You might be bitten by a bug, or perhaps undocumented misfeature, that bit me this morning. No emails were coming in and yet the mailserver logs said they were coming in, but a closer look at the logs showed this:

Aug 15 09:08:17 elmo dspam[24896]: dlopen() failed: /usr/lib/dspam/libpgsql_drv.so: /usr/lib/dspam/libpgsql_drv.so: cannot open shared object file: No such file or directory

What happened here? A quick look at the installed packages said the pgsql backend was still installed but this file was not being found.

The latest version of libdspam7-drv-pgsql now has multiarch support which means /usr/lib/dspam no longer exists and the driver is found in /usr/lib/x86_64-linux-gnu/dspam. The problem happens because the configuration file specifies the directory and that has now changed. The fix is as simple, update /etc/dspam/dspam.conf with the new path.


Comments

4 responses to “Be careful with dspam and multi-arch”

  1. I will add a NEWS entry about this, I must admit I had thought of it and then forgotten…

    Thanks for noticing

    Julien

    1. No probs Julien. We’ve all done that in packaging “what, I’m SURE I did (or didn’t do) that before I uploaded”. Thanks for looking after it as it sure works well (99.1% accurate). I basically put a blog entry in to try to catch some others that might cop it.

      Yeah, a NEWS entry would definitely help (if I read them which I almost always do, except when it happens to coincidently be important to me and then wonder why something broke).

      Oh, and I love that icon you have!

  2. Why is dspam hard-coding plugin paths in configuration files?

    1. Good question! It does seem a bit strange.

Leave a Reply

Your email address will not be published. Required fields are marked *