On Sat, 2014-05-24 at 02:36 +0200, Karsten Bräckelmann wrote: > On Sat, 2014-05-24 at 01:10 +0100, Martin Gregorie wrote: > > On Sat, 2014-05-24 at 01:12 +0200, Karsten Bräckelmann wrote: > > > > > > The yum upgrade replaced three Perl libraries: > > > > > > Is that everything that was upgraded, or just the Perl bits? > > > > Just the Perl bits. > > Figured as much. That rather rhetorical question was meant as a gentle > hint for you to dive down other upgrades, possibly listing them here. > Something changed, something broke. Coincidence? ;) > 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.
I'll post the complete list either later today or on Tuesday (this is the start of the second May Bank Holiday weekend). > > > Martin, is spamd running and responding? Try pinging it: > > > > > > spamc -K > > > > Yes, when I started it. 'spamc -K' said SPAMD/1.5 0 > > 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. I have another script that copies the SA configuration from the testing box to the live machine and then restarts the live copy of spamd. That said, the run-time environment of spamd on the testing machine is as near to identical with the live system as I can reasonably make it. Martin
