Open Sourcery

Since I last announced Capistrano support for daemon-kit, a few other things have happened that is steadily moving the project forward. Here is a synopsis of them all:

No more daemons

Sounds contradictory, but I’ve stripped out the daemons gem as a depedency. Everything the daemons gem offered is now handled inhouse, and works much better. For more information please read the release announcement.

Better command line argument handling

A lot has been done to smooth out command line argument handling, and daemons can now tap into the command line processing very easily. Details in the release announcement and the RDoc.

Error mails now handled by TMail

Makes them look better and be better formed, the initial code didn’t really produce meaningful mails. A lot of work still needs to be done in this arena.

Log with vigor!

Logging got a lot of attention with the new AbstractLogger interface. Log rotation is now dead simple and logging to Syslog is possible thanks to the SysLogLogger gem. See the RDoc for more information on logging.

Cucumber

Still a lot needs to be done to simplify testing daemon processes, but the inclusion of preliminary cucumber support is one step in the right direction. I’m hoping cucumber will be a great fit for daemon-kit, and help us as daemon developers define the difficult contexts in which our code runs.

Looking forward

Plenty still needs to be done, the TODO file in the repo is some insight into what the future holds. Mostly daemon-kit evolves as I need it to for my production environments. On Github we’re close to 200 watchers, and the Google Group does have a little activity.

As time goes on I’m hoping more people get involved and bring suggestions to the table for the framework. So please, do tell me how daemon-kit can make your life simpler for your, and your daemons.

Daemon-kit has been getting a lot of TLC from me lately, and it’s not going to stop anytime soon. As I wander deeper and deeper into AMQP territory, I need to extend daemon-kit to cope with all kinds of new scenarios. One of those being unhandled exceptions.

The second thing I put on the TODO list was Rails-style exception handling. With version 0.1.6 there has been some progress made in that regard. Daemon-kit now sports a configurable safety net for dangerous code. By wrapping blocks of code in a “safety net”, unhandled exceptions are caught and logged, and optionally sent via email or to Hoptoad for review.

Hoptoad? In a Ruby daemon? Sure, inspiration came via these tweets.

And it only makes sense to do it. Now for some code:

safely do
  # do something silly
  silly.action!
end

safely is mixed into Object and can be used freely. It is important to note that you have to handle your daemon-specific applications on your own and rely on safely as a fall over mechanism.

To configure the safety net, you can edit your config/environment.rb file and add the following lines to the configure block:

  # for email notifications
  config.safety_net.handler = :mail
  config.safety_net.mail.recipients = ['you@gmail.com']
 
  # for hoptoad
  config.safety_net.handler = :hoptoad
  config.safety_net.hoptoad.api_key = 'your-hoptoad-key'

The documentation is very rough at the moment, but the files you want to explore are lib/daemon_kit/safety.rb and the error handlers in lib/daemon_kit/error_handlers.

NOTE: If you are upgrading from an earlier daemon-kit, please upgrade your daemons as well by running the following rake task in the root of your daemon projects:

$ rake daemon_kit:upgrade

In the coming days/weeks you can look forward to the following enhancements as well:

• Improved logging
• Improved backtrace cleanups
• Improved rdoc’s
• rack application generator (with rack-mount)

I’m patching things up as I go along, adding features as I need them (and stuff I recall from my first daemons). There is still a lot of things that need attention, but they’ll be addressed and hopefully daemon-kit grows to becoming the premier framework for writing daemon processes in our beloved Ruby.

I started conceptualizing and playing with a pet project called daemon-kit earlier this year, with the aim to ultimately be the preferred way of assembling daemon processes written in Ruby.

Today I took the opportunity to add two more generators to daemon-kit, as well as fix some small annoying issues. The first generator is a ‘cron’ generator, which I’ll cover in this article. The second is an AMQP consumer, that my day job requires.

Running cron-style daemon processes seems to be a common need in the Ruby world, and my first ever daemon process was a cron-style implementation using the remarkable rufus-scheduler gem by John Mettraux. The second, an SQS client. Writing Ruby daemon processes is quick and simple, but getting to know the ins and outs of these hidden beasts can be quit a nightmare.

As of late I’ve been threatening in #ruote that daemon-kit will sport a ‘cron’ style generator when I get the time. Today I made time, and you can now get a simple cron daemon up and running in minutes, heres how:

1. Get daemon-kit & co

$ sudo gem install kennethkalmer-daemon-kit
$ sudo gem install rufus-scheduler

rufus-scheduler is not a direct dependency of daemon-kit, but required by the daemons generated using the cron generator.

2. Generate a stub daemon

$ daemon_kit mycrond -i cron

This creates a project layout in a directory named ‘mycrond‘. You can populate the lib folder with your custom code. What matters though is that your generated ‘cron’ daemon lives in libexec/mycrond.rb.

3. Profit

Open up libexec/mycrond.rb to reveal a fully functional cron-style daemon, complete with sample 1 minute task.

Behind the scenes

All of daemon-kit is basically two things: abstracting daemonizing routines and environment configurations, and wrapping supporting libraries in thin wrapper classes for easing their use inside daemon processes. The cron wrapper class is extremely thin, in part due to the excellent implementation of the rufus-scheduler gem.

As with all projects, I cannot imagine every possible use for the gem and rely on feedback from the community. If you are going to attempt using ActiveRecord inside the cron daemon, beware that you might have to juggle some balls with ActiveRecord and threads. Please report these issues on the github tracker and I’ll attempt to find solutions for you. I highly recommend using ActiveRecord 2.3.2 or later to benefit from the connection pooling and thread safety improvements.

Just as a quick update on the PowerDNS on Rails project, I’ve just pushed several updates to Github that most profoundly includes support for audits. Other smaller changes are also included, including plugin updates (HAML) and upgrading Rails to 2.0.4. As always, these updates have been running in production for a couple of hours already and has solicited some review from our support staff. Undoubtably there will be a lot of tweaks to the feature in the coming days…

Next on the radar is authentication tokens, allowing to give users one-time access to a specific domain for performing updates.

We’ll keep you posted!