I am finding the need for custom Linux service scripts more and more. This is in the case where a program I want to run in the background does not already have one for one reason or another. Maybe I’m compiling instead of using apt, or sometimes I am creating my own app.
In the past I’ve used the traditional init script format that exists in /etc/init.d. This proved to be tedious. Unless I already had the init script on hand, I would need to code it out in bash script, like so:
#!/bin/bash
#
# Debug SMTP Service
#
case "$1" in
start)
if [ -f "/var/run/debugsmtp.pid" ]
then
echo "Service already running"
else
echo "Starting service..."
python -m smtpd -n -c DebuggingServer localhost:25 &
echo "$!" > /var/run/debugsmtp.pid
echo "Service started"
fi
;;
stop)
if [ -f "/var/run/debugsmtp.pid" ]
then
PID=`cat /var/run/debugsmtp.pid`
kill -9 "$PID"
rm /var/run/debugsmtp.pid
if [ ! -f "/var/run/debugsmtp.pid" ]
then
echo "Service stopped"
fi
else
echo "Service not running"
fi
;;
*)
echo "Service"
echo $"Usage: $0 {start|stop|status}"
exit 1
esac
exit 0
As you can see, there are sections to handle different commands, in this case it is just start and stop. With other programs there may also be restart, status and reload.
Start checks if the process is already running by checking if a PID file exists. If it does, then the service is assumed to already be running. If not, the script goes on to start the process and stuffs the process ID into a newly created pid file at the same location.
Stop is similar, as in it works on the PID file. It will check if the process is running by checking the pid file, and if it does, it will run a kill command on the process.
Phew.
Setting this up for multiple systems is a pain, and it is more technical than I would like to be doing on a routine basis. Specifically, managing processes with PIDs and using the kill command makes me a little nervous.
But there are other problems I could run into that would run into some shortcomings of init.d. One being the ability to base the daemon’s start on the network interface being up, or the filesystem being ready. This would apply to applications such as web and SMTP servers.
Enter upstart.
Upstart came into play in 2006 (at least in the Ubuntu world). It is a replacement of the previously mentioned init system where scripts are placed in /etc/init.d and /etc/rc*.d folders. It has a more accurate boot sequence through event based start up, and take less effort to implement due to some tasks like PID management being automatically handled.
Upstarts are configured with stanzas. Two of those being start and stop, where you use runlevels or events (network up, filesystem ready) to define when the daemon should be started and shutdown. When it’s all set it looks like this:
description “nginx http daemon”
# Start daemon when filestyem and network interface is up start on (filesystem and net-device-up IFACE=lo) # Stop daemon when runlevel is not specified levels stop on runlevel [!2345] # Daemon binary location env DAEMON=/usr/sbin/nginx # Daemon pid location env PID=/var/run/nginx.pid # Indicate daemon has child processes expect fork # Restart if daemon ends prematurely respawn # Max respwans respawn limit 10 5 # Commands to run before daemon starts pre-start script $DAEMON -t if [ $? -ne 0 ] then exit $? fi end script # Run daemon exec $DAEMON
Conclusion
So there you have it. Upstarts make life easier by cutting your daemon initialization scripts in half with more control, and less being in the weeds. It’s ideal for custom or compiled applications (packages often install their own init scripts) and removes the need to boot up a daemon every time you start your machine.