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.
