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.
4 thoughts on “Be careful with dspam and multi-arch”
I will add a NEWS entry about this, I must admit I had thought of it and then forgotten…
Thanks for noticing
Julien
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!
Why is dspam hard-coding plugin paths in configuration files?
Good question! It does seem a bit strange.