If you’re going to write an init script, do it properly

“How do I make my Linux process auto-start?” is a fairly common question.  The answer is fairly simple, thank goodness.  Write a shell script, put it in /etc/init.d and run <code>update-rc.d myScriptName defaults</code>.  And you’re done.

Except you’re not, probably.  If you haven’t written your script correctly, you might well hang the boot process.

Init.d and all those rc.d folders are part of the Unix System V init process.  Unlike modern replacement Upstart, init starts processes in series, never in parallel.  If your startup script doesn’t exit, then init won’t either.  If you’re written a really lazy script that doesn’t detatch after starting a process, then you’re screwed 🙂

Another thing to watch our for is how your script is called.  Init will pass either “start” or “stop” to the script depending on what the process should be doing.  If you don’t handle the difference between these (in a case statement, say) and instead just execute the same code whenever the script is run, you’re going to have a really fun time when you try to shutdown or restart your server.  Especially if your script doesn’t detatch and hangs init.  Because then you’re not going to be able to shut down your server cleanly.

It’s been a fun week for my test VMs!

Here’s a little bonus for you.  If you want to start several processes in a specific sequence, you can do this by writing your startup scripts so they don’t exit until each process is ready.  Init allows you to determine the order in which you start processes within a runlevel (that’s what the numbers in the symlink filenames mean) and you know from the above that you can prevent init from processing the next script in it’s queue.  Use this knowledge wisely.

Leave a Comment