The Right Hump

sa-compile should speed up SpamAssassin, by pre-compiling rules into Native code.

Seem like you run sa-compile once, and the debian cron job takes care of re-running sa-compile whenever the rules are updated.

Trouble for me is that the load on the NAS of the compile took it down.

Since I have the cross compilers on my desktop PC, I figured it should be possible to build the native rules there, and distribute them to all the NAS drives.

Cross compile packages installed

acid:~# dpkg --get-selections | grep -e gnueabi -e armel

binutils-arm-linux-gnueabi install cpp-4.4-arm-linux-gnueabi install gcc-4.4-arm-linux-gnueabi install gcc-4.4-arm-linux-gnueabi-base install gcc-4.4-base-armel-cross install libc6-armel-cross install libc6-dev-armel-cross install libgcc1-armel-cross install libgomp1-armel-cross install

Compile the rules into some directory

export PERL_MM_OPT="CC=arm-linux-gnueabi-gcc LD=arm-linux-gnueabi-gcc AR=arm-linux-gnueabi-ar"


sa-compile --updatedir /root/sa-updates

I'll probably use a combination of scp and incrond to distribute the rules

Categories: Debian, LinkStation, Linux

Just been suffering from an odd SpamAssassin timeout issue. Some mails were taking forever to scan. Timing out (and being allowed thru, as per config). Running them through

spamassassin -D < blah.msg

had them scanned in about 60 secs.

Running with

spamc -c < blah.msg

was timing out after 10 minutes. strace showed the spamc client was never receiving the response from spamd, and running spamd in debug mode I could see the scan finishing after about 1 minute

Anyway, turns out default in Debian is to run the scan over port TCP/IP 783, I found changing it to a UNIX domain socket fixed the issue.

/etc/default/spamassassin OPTIONS="--create-prefs --max-children 4 --helper-home-dir --socketpath=/var/run/spamd.sock"

/etc/exim4/sa-exim.conf SAspamcSockPath: /var/run/spamd.sock #SAspamcHost: 127.0.0.1 #SAspamcPort: 783

That scan now completes in under 60 secs.

Categories: Debian, Linux