Common Daemon Interface

gistfile1.sh

# Common Daemon Interface is a emerging standard, its only purpose is to define portable daemon specifications understandable and interchangeable between
# various service and process managers. Primary targets are launchd, upstart and systemd and the ones known to be widely used and fairly similar.

# Feedback welcome.

# required settings
SERVICE_NAME="my_cool_service"                                           # alphanumeric string, underscores and dots are allowed
DAEMON_INTERFACE="CDI/1.0"                                               # daemon interface version
SERVICE_TYPE="daemon"                                                    # (task|daemon) wether process is a one-time job or background daemon

# generic options, all optional

PROCESS_COMMAND="bundle exec rake test"                                  # program to run, arguments inline
PROCESS_USER="bulat"                                                     # user to run the process under
PROCESS_GROUP="staff"                                                    # group to run the process under
PROCESS_ROOT_DIR="/srv/chroots/oneiric"                                  # chroot
PROCESS_WORKING_DIR="/var/mydaemon"                                      # chdir
PROCESS_UMASK="0775"                                                     # umask
SERVICE_SOCKET="tcp://127.0.0.1:5000"                                    # socket is specified as a uri in form of <protocol>://<socket string>, <protocol> is one of (udp|tcp|unix)
SERVICE_SOCKET="unix:///path/to/unix/domain.socket"                      # <socket string> is ip:port for network sockets or just path for unix
SERVICE_SOCKET="tcp://127.0.0.1:5000,unix:///path/to/unix/domain.socket" # multiple sockets can be specified in a coma-separated list without trailing whitespace

# resource limits, refer to setrlimit(2)

LIMIT_CORE="5,0"                                                         # specified in a form of <soft limit>,<hard limit>
LIMIT_CPU="0"                                                            # hard limit is optional, same value should be used for both if only one value is supplied
LIMIT_DATA="0"
LIMIT_FSIZE="0"
LIMIT_MEMLOCK="0"
LIMIT_NOFILE="0"
LIMIT_NPROC="0"
LIMIT_RSS="0"
LIMIT_STACK="0"

There are so many approaches and features that modern init systems has, that is going to be hard to encapsulate them all, much less make them work with everything.

My personal suggestion is that vendors and packagers ship two things:

1. A CDI-enabled initscript that sources these variables from /etc/default, and a library that makes the magic just happen. Think of it as an extension or an enhancement of the LSB init script libraries shipped in all distributions. That's where the market for CDI is.
2. A systemd service file, either generated at build time from these values (which could probably be a responsibility of the CDI toolkit), or kept in sync with those values.

Also keep in mind that the CDI can only cover a tiny subset of all the possibilities in which a system can interface with a daemon and vice versa. Modern systems have things like service dependency declaration (both in terms of ordering and in terms of requirement), private /tmp's, cgroups, even full or partial containers associated with them. Implementing all of this as a CDI, in a manner that is going to be compatible with all or even just popular init systems, is going to be practically impossible. Lennart took over a year implementing systemd (most of which was spent on the transactional part of the software), and that was only for a single init system, and it wasn't even feature-complete after that.

systemd was designed to solve all problems of all init systems that existed before it, and -- as it happens -- it actually does. The vendor need only drop a file in a directory, and then run "systemctl enable" to make sure his program works properly and starts on boot. And all the features that CDI promises to offer, systemd delivers too. Thus, in my opinion, it is best to keep CDI as an augmentation for the most common use cases, and remembering that eventually it will be fully obsoleted by systemd.

What do you guys think?

Also, you should probably post on the freedesktop mailing list where systemd devs congregate, to find common points and reuse same approaches. Also see http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart to get an idea of what not to reimplement unnecessarily (just implement as compatibility).