Mapping an upstart job to a init.d script (sssd)

Erich Schubert erich.schubert at
Thu Apr 29 18:43:04 UTC 2010

A reason why I havn't been convinced with any of the init systems so
far, is because they in my opinion lack proper tracking of the
services started. At most will they monitor a pid file (which actually
is quite fragile).
daemontools, minit, runit and similar systems are a bit more advanced,
in that they can properly monitor services that do not background
themselves (which, mind it, is a common but ugly hack!). But they fail
for me for non-daemon tasks that make up the other half of our init
systems. In some cases (minit), it seems to even be a design goal to
save the effort of starting a shell, while in fact just about any init
script in debian will currently use shell features such as parsing for
/etc/default/$DAEMON for configuration options. Disabling and Enabling
of services is another example where these systems are not really
usable - they are designed for an admin that does everything by hand
(which may be common for *BSD users, but is not a desire of Debian).
This also is fragile when it comes to change tracking, package
updates, version control of configuration etc, since there is no way
to differentiate a "lost" file from a "deleted" file, while setting a
shell variable to "disabled" in the file /etc/defaults/$DAEMON is a
lot more reliable.

But enough ranting. In fact, I havn't been keeping up with init
developments, so many of these issue may have been addressed in the
meantime for runit etc.; I believe that upstart at most does pid file
monitoring, and not makes use of PID 1 special properties (i.e.
getting signals when daemons die). The main goal of this mail is to
remind you that we SHOULD ideally support more than one init, and
metainit might be useful for this.

best regards,
Erich Schubert

More information about the initscripts-ng-devel mailing list