run templates for runit/s6

From: Avery Payne <avery.p.payne_at_gmail.com>
Date: Fri, 3 Oct 2014 23:21:50 -0700

Submitted for constructive criticism:

--- 8K cut here 8K ---

#!/bin/sh

# redirect stderr to stdout...
exec 2>&1

# the daemon's name is the name of the script
DAEMON=$( basename $( pwd ) )

# support Debian's use of program detection before
# launching, and abort the run if not present.
[ -f /sbin/$DAEMON ] || \
[ -f /usr/sbin/$DAEMON ] || \
[ -f /bin/$DAEMON ] || \
[ -f /usr/bin/$DAEMON ] || exit 1

# attempt to load any Debian-specific environment
# settings from a control file.
[ -f /etc/defaults/$DAEMON ] && . /etc/defaults/$DAEMON

# if we have a set of daemon-specific options
# required to background the process, then load
# them from a local option file into DAEMONOPTS.
DAEMONOPTS=""
PRELAUNCH=""
[ -f ./options ] && . ./options

exec $PRELAUNCH $DAEMON $DAEMONOPTS

--- 8K cut here 8K ---

This is the "simple daemon" launch that I was referring to. It's not meant
to cover all use cases, just those cases where the daemon has simple needs,
and the service name matches the program name. To use it, the run file in
the service directory becomes a symlink to ../.template/simple-service.
The shell is assumed to be dash, which is normal; /bin/sh typically links
to /bin/dash in Debian installs.

The "probe to see if it really is installed" is an unfortunate necessity as
Debian allows the init.d script to be left in place even when the program
is removed, and one of my goals is to support the "drop in and replace SysV
init scripts" feature; so this is a rough emulation of that behavior. Yes,
the init.d scripts really do silently abort if the program is not present.

The loading of environment variables from /etc/default/(name) is also a
Debian-ism. The script really doesn't do anything with it other than make
sure the environment is set up before launching; some programs "absorb" the
settings, others explicitly need them defined in the run script. Beyond
loading them into memory I'm not making a further effort to pass flags to
the program, or settings to the script. Some of those settings do nasty
things like overriding or modifying the init.d behavior.

To get around the problem of "every program has its own set of option
flags", I've dumped them (and other pre-launch requirements) into a single
./option file that is pulled in by the script. After thinking about it
from a prior post, I figured this was the lesser of evils, especially if
the project might turn into a .deb file someday, which implies I might run
afoul of packaging requirements. As an added bonus, options are
individually confined to their service directory, and you can
easily/quickly tinker with settings by editing the file, and restarting the
service. It's not elegant but it's tidy, simple, and somewhat portable.

I haven't gotten the s6 image up and running yet, so I don't have anything
for s6-scripts. Hang in there - I hope to have a image up and get the
source pulled in and built sometime this weekend. I looked briefly at how
the service directories are set up, and I'm hopeful that I might be able to
cross-pollinate both with similar (or the same) scripts when possible.
Received on Sat Oct 04 2014 - 06:21:50 UTC