init.d is exactly like the grinchinit.d is exactly like the grinch

We’ve hit the dreaded seven day mark here so I guess I’ll run my rainy-day story about init.d.

This is an amateur’s guide to getting a freaking app server to start automatically when your Debian-based (Ubuntu) box reboots.

Surprisingly, a lot of Java programmers have convinced themselves that starting good ol’ Tomcat manually is good enough. Perhaps their Java webapps are so poorly written they need human intervention to human intervention every few days to keep running anyway. Or maybe they want to give the three guys paid to keep the application running something to do.

Neither of those applied to me but I still slacked for over a year on sorting out my own start-up configuration. technically.us runs for months on end without a hick-up, so who cares about rebooting? NYC electrical service is remarkably stable, being underground, and I’ve even taken international vacations without worrying about it too much.

Not that I didn’t try to learn. I would search around, find some really complicated discussion using the word daemon way too much, and just drop it. (Q: Whatever happened to autoexec.bat? A: rc.local, and don’t use it.) But when I was setting up this site with RimuHosting, they tell you plainly that you’re crazy if you don’t configure your server such that it can be rebooted and restored to service without your frantically typing fingers. What kind of animals are we Java programmers that they have to tell us such an obvious thing? The idea is too make lots of sites, sell them to people, and then basically forget about them administratively. Anything else is not worth the trouble.

Step 1: Understand what’s in /etc/init.d

I had figured this much out already. The scripts in /etc/init.d control your services. They are very handy. You call them (usually with superuser privileges) followed by a command like start or stop. The better ones support reload to read configuration files without interrupting service; you can usually get a list of options by running the script with no parameters.

All Debian packages that include services install an init.d script. Since Tomcat is available with Ubuntu, yes, it has the script in place. But the server itself is configured like a crazy old New Yorker’s apartment door with security measures that will definitely prevent your app from running until you figure out how to turn them off. Also, it’s Tomcat. As great as Ubuntu-supplied packages are, you’re better off not depending on them completely; who knows when you may need cook up something thoroughly home-grown (a slave Ruby service for Databinder dispatch, perhaps?).

Step 2: Ignore what’s in /etc/init.d

The package provided init.d scripts are great to use, but they aren’t a good models for the script you need. You only need to support start and stop. If you don’t do a lot of shell scripting, that sounds just annoying enough to induce procrastination, but the bare minimum init.d script is dead simple to type. (Yes, type. It’s like twenty characters.)

#!/bin/sh

case "$1" in
    start)
        /usr/local/geronimo/bin/geronimo.sh start
        ;;
    stop)
        /usr/local/geronimo/bin/geronimo.sh stop --user system --password manager
        ;;
esac

exit 0

This little ditty calls Geronimo’s management script (which would be a fine init.d script on its own if it didn’t require you to login to stop it). I have no idea if it’s optimal, but it works.

The only other thing it do is get links installed in the /etc/rc?.d directories. Again, Coderspiel neither knows nor cares about the specifics here, but update-rc.d <myscriptname> defaults does the trick. I rebooted. Server started, yay.

And I have a great excuse for lagging on weblog posts. I’m writing weblog software.

Codercomments

Nice article, spot on about the reality of Java web apps ;)

Add a comment