On Sat, 2014-05-24 at 05:04 +0200, Karsten Bräckelmann wrote: > On Sat, 2014-05-24 at 03:28 +0100, Martin Gregorie wrote: > > On Sat, 2014-05-24 at 02:36 +0200, Karsten Bräckelmann wrote: > > > I've looked down the list a couple of times and didn't see anything I > > thought would affect it due to a possibly bad assumption that this sort > > of error would be insulated from the underlying binary code by at least > > one layer of Perl library code. > > Plain spamassassin script works, spamc/d combination does not. Nope, > this is not necessarily related to any Perl code. > OK.
> Looking through the full list of upgraded packages, the two SELinux > related ones stick out. In particular, since the client / server > environment is affected, but not the standalone variant of calling the > majority of shared SA Perl code. > SELinux shouldn't be an issue as its running in Permissive, Targeted mode and it hasn't flagged up any warnings. > > > > By "started it", do you mean starting the daemon simply for that test, > > > or did you ping spamd after launching your dev test rig? > > > > Yes, I meant starting it. As I said, this problem surfaced on the box I > > use for SA rules development, actually a Lenovo laptop. Consequently SA > > only runs on it during a rules test: all my test scripts are written to > > start spamd, run the test and stop it. > > > > > Clean room vs. production conditions... > > > > Yes, exactly. > > Nah. I was talking about the difference in your test (manually starting > spamd) and the environment observed to fail (your dev test rig script). > Should be the same as live operation: my scripts use systemctl to start spamd as a systemd-managed service, so spamd is running as root. ps reports the commend line as /bin/spamd -d -c -m5 -H -r /var/run/spamd.pid > Unrelated to the problem at hand, but Fedora 18 and Fedora 20 does not > account for "as near to identical" as reasonably possible. > Sure, but when I set up the test environment I made sure that spamd was always started the same way as it would be in a live environment: the only difference is that its only running when I have testing to do. In any case this is a bit of a blind alley since the testing system was working just as I expected it to yesterday morning and then, after the yum upgrade the unmodified test system no longer worked that way. LATER: This morning I reran some failing examples after rebooting the test machine. No change, so I tried a few stripped-down runs, i.e. I started spamd via a test script that uses systemctl to start or stop it and then used "spamc <testmessage" to exercise it while I played round with spamc options. In the course of this I noticed a strange effect: The FIRST message after restarting spamd never has X-Spam headers, but the second and subsequent ones do have X-Spam headers. I'm running these versions: $ spamd --version SpamAssassin Server version 3.3.2 running on Perl 5.18.2 with SSL support (IO::Socket::SSL 1.955) with zlib support (Compress::Zlib 2.062) $ spamc --version SpamAssassin Client version 3.2.4 Should the spamc/spamd version mismatch have any bad effects? The only SA package I have installed is spamassassin.i686 3.3.2-56.fc20 which came from atrpms. This is odd, since all the uninstalled packages (spamass-milter, spamass-milter-postfix, spamassassin-FuzzyOcr, spamassassin-iXhash2, spambayes, spampd, spamprobe.i686) are from Fedore repositories as you'd expect. Removing and reinstalling the spamassassin package has had no effect. I'll take this up with RedHat next week and see if I can find out why they no longer provide the main spamassassin package in their repository. Martin
