Ideally you’d ship no init script and let downstream packaging figure it out, since there are even more init systems than there are package formats: various versions of SysV init;
upstart for old versions of Ubuntu;
systemd for new versions of Ubuntu, Debian, and Red Hat; OS X launchd for all those Homebrew users; and if you’re generous, or a masochist, the several variants of BSD rc.d; Solaris SMF; or even Windows Services.
If you don’t have the luxury of being popular enough that distros package for you, or you’re working on in-house stuff, then you might end up writing a SysV init script. It won’t be portable. Even if you’re using
daemonize to handle the hard stuff like daemonizing, PID/lock files, and running as a non-root user, there are still little matters like the helper functions you need even with
daemonize to kill the process or get its status. Are they in
/etc/rc.d/init.d/functions? Are they in
/lib/lsb/init-functions? Does your target system actually have either, and if so, what’s in them? Do you need to run Red Hat
chkconfig after installing the script? How about Debian
update-rc.d? Do you need an
INIT INFO block? Does your target system claim to use LSB-compliant init scripts? Which LSB version? Do you really need all those entry points? Are you going to test it on
upstart systems to see if their SysV backwards compatibility actually works?
OK, for modern systems, you can probably get away with just
launchd, but no wonder a lot of new kids think “background service” means “run it in