Google Analytics

Friday, May 15, 2009

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.

Tuesday, May 12, 2009

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!

Friday, May 08, 2009

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.