Between 9pm and 10pm PST last night, Dreamhost (and reportedly TextDrive) decided to upgrade to Rails 1.1, resulting in mass havoc, confusion, and probably a few tears. Typo isn’t compatible yet, so bloggers all across the Rails-o-sphere cried out in silence.
Personally, I was hoping for such a world-ending event so I could try my new server monitoring tool. It worked!
For Typo (or other Rails apps), you can fix it by copying Rails 1.0 into the “vendor” folder. Of course, if your app isn’t running, you can’t do this on your server. Here’s what I did:
1. Freeze Rails 1.0 on any Rails app on your computer:
rake freeze_edge REVISION=3303
2. Copy the newly frozen contents of “vendor/rails” to your remote app’s “vendor/rails” folder.
Or, some people are having both success and failure by doing this on the remote server:
svn export http://dev.rubyonrails.org/svn/rails/tags/rel_1-0-0/vendor/rails
Ryan Davis has repeatedly recommended dwatch, a simple app that you run with cron. It reads a config file and checks to see if sites are responding. You can also have it scan the list of currently running processes on a machine. In either case, it runs a command of your choosing if the service is down.
I dusted off my C reference and expanded it to run the curl command to see if a running site returns an error (an HTTP status code of 400 or greater). Here is the modified app:
I run this with cron every hour. If there is an error, I have it echo an error message. My shared host (Dreamhost) automatically emails me the output of cron tasks, so I get an email when something goes wrong. If everything is fine, it is silent and no email is sent.
Here’s what I saw in my inbox after Dreamhost upgraded to Rails 1.1:
Installation is pretty simple, but requires the compilation of a C file. Unzip the app on your server and do:
make make install PREFIX=~
I use prefix-tilde so it installs in my home directory. All that matters is that you have a “bin” directory for the compiled app to be copied to.
It expects to find curl in ”/usr/bin/curl”, which seems to be the default for Linux and Mac OS X. You can also configure that with a flag to make (see the README).
Cron is a standard Unix tool to run tasks at regular intervals. I make a file with my cron tasks and load it into cron all at once.
# Local crontab config file # Save as my_cron_tasks.txt @hourly /home/topfunky/bin/hourly.sh @daily /home/topfunky/bin/daily.sh
Load that file into cron with this command:
topfunky$ crontab my_cron_tasks.txt
The hourly shell script looks like this
#!/bin/sh # Hourly shell script # (You might be able to do this with # paths relative to your home directory.) /home/topfunky/bin/dwatch -f /home/topfunky/conf/dwatch.conf
Finally, make your hourly shell script executable so it can be run:
topfunky$ chmod +x bin/hourly.sh topfunky$ chmod +x bin/daily.sh
In summary, that will run the hourly shell script once an hour (the exact minute varies). The hourly script runs dwatch with its config file. If dwatch produces any output, it will be sent to the administrator’s email (depending on your shared host).
You can also pipe the output of the hourly script to the “mail” command. See “man mail.”
Earlier I said that I have dwatch configured to check a few sites and echo a message if an error happened.
Dwatch can check any site and perform any command if the site is unreachable. Here’s a sample:
# Sample dwatch.conf H "nubyonrails.com/tools/pluralize" echo "The pluralizer returned an error!" H "nubyonrails.com" echo "nubyonrails returned an error!"
The H is my addition…it checks the HTTP status code of the site. The second part is the site (or page) to check. The last element is the command to run.
The built in options also include T (check for a TCP listener…you must specify a port) and P (checks the local process list for a running process that matches).