Deep Thought

2009-01-20 19:00:00 -0500


I need an HTCPCP daemon.

Or an intern.

There is coffee all over the world. Increasingly, in a world in which computing is ubiquitous, the computists want to make coffee. Coffee brewing is an art, but the distributed intelligence of the web-connected world transcends art…

I’m gonna go make some coffee. Blog post on really simple ruby daemonizing coming soon. Stay tuned.


Dead Simple Ruby Daemons Using Looper

2009-01-20 19:00:00 -0500


There seems to be a bit of interest in the Ruby community lately in putting together handy libraries for creating Ruby daemons, so I thought I’d throw our own particular solution into the mix. Our solution intentionally avoids a lot of the common daemonizing tasks (like detaching from the terminal) so it might not be quite appropriate to call it daemonizing, but it fills our requirements nicely. (As an aside, check out Kenneth Kalmer’s new library daemon-kit for a nice actual-daemon implementation in Ruby.)

We originally tried coding things by hand using Daemons, and then modularizing our oft-repeated code to stay DRY, but we kept running into stability issues. Also, when you fork a Ruby daemon, particularly one that’s loaded up a large stack in memory, you end up at least briefly using twice as much memory. So, memory hogging and crashing needed to be avoided.

None of our daemons required advanced process handling, either. They were simple, single instance workers that had very particular tasks (like schedulers and message handlers for PingMe). We found ourselves asking, “do we really need to be forking child processes for this?”

The answer is no. Instead we are using a module we just pushed to Github that we call Looper. It allows us to take any bit of code or a class and run it as a kind of daemon. Or, more specifically, the class uses Looper to take advantage of its simple signal trapping, loop handling (including sleeping), and the class can rely on Looper to catch any unhandled exception, report it, and keep on keepin’ on.

The loopme method takes a block that it runs for you, handles sleeping between runs, and will catch any unhandled exceptions that bubble up. Thus, if you want to exit on a particular exception, you’ve got to rescue it in your code and set @run to false. It also sets up signal trapping so that signals TERM, INT and HUP will all cause the loop to end (I’d be open to changing this behavior or adding additional signal responses if anybody has an interest).

Here’s an example “daemon” that uses looper to kick it:



require 'looper'
require 'twitter'

class DoSomething
include Looper

def initialize(config)
@run = true
# do config stuff, etc...
@sleep = config[:sleep].nil? ? 60 : config[:sleep]
end # initialize

def run
loopme(@sleep) do
begin
# this is where the meat of your code goes...
messages = twitter.direct_messages({:since => Time.now.strftime("%a, %d %b %Y %H:%M:%S %Z")})
rescue Twitter::EpicFailure => e
puts "bailing out, dude!"
# set run to false to put the kabosh on the next run
@run = false
end
end
end
end

# and here's how we kick it off:
DoSomething.new( { :sleep => 10 } ).run

Pretty simple, right? No coding up the signals, the sleeping, the global exception handler, etc. You can take a look at looper.rb to see exactly what it does for you. From here, starting and stopping our script is really easy, and can be re-used for each of our daemons. It boils down to starting it up with nohup (and script/runner because we like having our rails stack), and then killing it later with the PID:

$ nohup script/runner -e RAILS_ENV /path/to/DoSomething.rb

There’s no need to use Rails’ script/runner, you could just call ruby itself and save yourself a lot of memory ;-)

The following is an init script that we use to start and stop any of our Looper daemons:



#!/bin/bash
#
# chkconfig: 345 70 30
# description: control script for daemons
#

usage(){
echo $"Usage: $0 {start|stop|restart} {daemon1|godzilla|voltron}"
}

# daemon name is required as second param
if [ "$2" = "" ]
then
usage
exit 5
fi

# RAILS_ENV?
if [ "$RAILS_ENV" = "" ]; then
RAILS_ENV='development'
fi

# RAILS_DIR?
if [ "$RAILS_ENV" = "production" ]; then
RAILS_DIR='/www/app/current'
else # assume development
RAILS_DIR='/www/dev.app/current'
fi

PROGRAM="${RAILS_DIR}/daemons/${2}/looper.rb"
RUNNER="${RAILS_DIR}/script/runner"

LOG="/var/log/app/daemon_${RAILS_ENV}.log"

# if the daemon is missing, well, the daemon is missing!
test -f $PROGRAM || exit 5

# See how we were called
case "$1" in
start)
nohup $RUNNER -e $RAILS_ENV $PROGRAM >> $LOG 2>&1 &
;;
stop)
PID=`ps auxw | grep ${PROGRAM} | grep -v grep | awk '{ print $2 }'`
echo "Stopping PID: ${PID}"
kill $PID
sleep 2
;;
restart)
$0 stop
$0 start
;;
*)
usage
exit 1
;;
esac

exit 0
Zetetic is the creator of the super-flexible Tempo Time Tracking system.

ckFormLogin and a happy user

2009-01-15 19:00:00 -0500


Today’s dose of win:

“Alright!! It’s working against the production servers – monitoring 6 web apps across three servers. My boss is very happy. That means I am even happier. I have been working with Nagios now for roughly 4 months. The user login test was the final piece of this project. Thanks again for the help.”

How cool is that? We have a plugin for Nagios called ckFormLogin that monitors login processes for popular asset management systems (Oracle CoreID Access Manager, CA eTrust Siteminder, Sun Access Manager, &c.), and when people have a little trouble with it, we’re pretty happy to help them out. But rarely do you get cool feedback like that.

Nagios itself is a really useful and highly configurable piece of monitoring software. The interface is a bit Soviet, sure, but it works great, and it’s open source. So is the ckFormLogin plugin.


Virus Utilization

2009-01-14 19:00:00 -0500


This post is probably not what you’d expect. But our time-tracker service Tempo has some great charting capabilities. Behold, the effects of a recent virus (of which I will spare you the horrific details) on my productivity:

Above is the Heads-Up-Display, at the top of the main screen. It reads pretty easily – my productivity was sent to bed!

Check out the utilization chart, which is a bit more instructive as to what happened, and when. That’s accessible by clicking the productivity percentage number box in the HUD, or just pulling it up from the Charts tab:

Brutal.

Utilization is a measurement concept in Tempo that is supposed to give you a ballpark idea how much of your time is accounted for, compared to how much time is generally available in a work-day. So, for every day in a report, the par for the day is considered to be 7 to 9 hours (which is a pretty common length for a workday), and that’s the horizontal, light-blue bar going across the graph between 7 and 9 on the Y-axis. The bars then show us a visual comparison of our utilization for the time periods. If I were to expand the date range enough, these would be grouped by week, then by month. Here’s what my utilization looks like since Nov 1st, 2008, until now:

So 2008 was a pretty productive year for us here at Zetetic. I can’t really go through it all right here and right now, but we’re quite excited about the new year, improvements we’ll be making to our existing products, and the new products and services we’re currently building.

And with that I’m going back to bed. Offers to send me comfort whisky, cheese burgers and nurses will not be turned away outright.


Tetris!

2009-01-10 19:00:00 -0500


I guess it kinda makes sense that Tetris could interrupt the brain from developing PTSD, it definitely interrupted my childhood for a few solid months at a time: (h/t Tim F.)

These results support Holmes’s theory that Tetris can help to prevent PTSD flashbacks by occupying the brain’s energies during the narrow time window when traumatic memories are consolidated. …snip…

But EMDR is only used to treat PTSD and there are several ways of doing that. Holmes’s goal is more proactive – she wants to find ways of preventing the symptoms from appearing in the first place. There are a few potential options for doing that, from drugs to psychotherapy, but few can be delivered so quickly or cheaply as a quick game of Tetris on a handheld machine. The game has another big advantage in that it affects a person’s reactions to an event but not their actual memories of it – Holmes notes that they would feel relief, but their ability to, say, testify in court wouldn’t be diminished.

Yes, I just downloaded the version that’s available in the App Store. What an easy preventative to make available for people — pretty much everyone has a cell phone, especially troops in combat. Doesn’t take much processing power or graphics to run Tetris!