Fixing the infamous Amavis + SpamAssassin cron messages

I'm using Amavis and SpamAssassin together on an Ubuntu server. For some reason, a cron email was being generated every 3 hours that looked like this:

bayes: synced databases from journal in 0 seconds: 811 unique entries (1420 total entries)

There is a bug report filed about it here but the solution didn't help me.

The file responsible for generating this message is /usr/sbin/amavisd-new-cronjob. I was able to stop the annoying messages by changing line 26 from:

exec ${CMD}

to

exec ${CMD} >/dev/null 2>&1

While this may clobber useful error messages as well, my care factor is low after being spammed so much.

Hiding windows with Ruby and appscript on OS X

At the moment I'm writing a Ruby script that interacts with iTunes on OS X. Fortunately this is fairly easy to do using the AppleScript bridge rb-appscript.

My problem was that I needed to hide the iTunes window (the same as using the ⌘H shortcut) so that the Ruby application didn't lose focus. Unfortunately it took me a long time to find out how to do it.

I didn't need to deal with OSAX. Here's a snippet of code that demonstrates the necessary incantation:

require 'rubygems'
require 'appscript'

itunes = Appscript.app('iTunes')
itunes.activate()
itunes.stop
# Hide the iTunes window
Appscript.app('System Events').processes['iTunes'].visible.set(false)

Here is what the actual AppleScript (which I was able to find easily) looks like:

tell application "System Events"
    set visible of process "iTunes" to false
end tell

You can see how the 'Rubyised' version maps to it, although it took a lot of Googling to translate!

Cryptic MySQL Error Message

I came across an interesting but cryptic MySQL error message today that took me a while to figure out.

After creating a bunch of InnoDB tables on this particular server, I tried to create some indexes and insert some data. Both types of operations failed with an error message that looked like this:

ERROR 1025 (HY000): Error on rename of './dbname/tablname' to './dbname/#sql2-12bb-9474d' (errno: -1)

After some looking around I came across this amusing bug report, which explained that this message could be due to the innodb_force_recovery setting being set to a non-zero value.

Sure enough, running SHOW VARIABLES LIKE 'innodb_force_recovery'; revealed that it was set to '4' instead of '0'. I now have a sys-admin to kill.