On Sat, 2014-05-31 at 20:15 +0200, Karsten Bräckelmann wrote:
> $ which -a spamc
>
'locate spamc' turned up a copy of spamc 3.2.4 in /usr/local/bin dated
2008. I can't remember how it might have got there since I've only ever
installed SA from the Fedora repo. Anyway, that is gone now and both
spamc and spamd are at version 3.3.2
The only copy of spamd is 3.3.2 and AFAICT there have never been
additional copies of it or spamassassin - also 3.3.2
> Given that still unexplained version mismatch, it is not unlikely there
> are bad installations of Perl libraries, too. Might be time to install
> the system fresh...
>
That happened a few weeks back when I did a clean install of Fedora 20.
This replaced all executables that aren't in /usr/local/bin:
the /usr/local directory is a symlink to /home/local and home is a
separate partition and is the only one on this system that isn't
reformatted during a clean install.
> > The testsa script looks like this:
>
> > state=$(spamdstatus)
> > if [ "$state" == 'spamd is stopped' ]
> > then
> > sudo systemctl start spamassassin.service
> > fi
>
> Most likely unrelated, though this code might potentially mess with
> spamd unnoticed. I'd get rid of that part while debugging the issue, or
> at least make it clearly print a warning.
>
This script looks like this:
#!/bin/bash
sudo systemctl status spamassassin.service 2>&1 >/dev/null
if [ $? -eq 0 ]
then
reply='spamd is running'
else
reply='spamd is stopped'
fi
echo $reply
So I don't see how it can mess with spamd. In any case the first time
failure happens regardless of whether testsa is allowed to start and
stop spamd of it it is started separately. The only difference is that
if testsa does the start/stop it always fails since every test it
submits is the first spamc request after a restart, while if spamd is
started separately, only the first test fails to scan the message: the
rest are OK until spamd is stopped and restarted.
> Apart from that, the issue surfaced after a system upgrade, without any
> SA code changed. Makes the distro the more likely place for reporting.
>
Yeah, I'll raise a bug with Fedora and spare this mailing list from more
bandwidth use.
Martin
