The Wanderer:
This is the problem. The init system should not be providing
> "features" which other software might, post-boot and pre-shutdown,
> want to make use of. (AFAIK sysvinit never did, and most - possibly
> all? - of the other init-system candidates don't either.) Such
> features should be provided separately, independent of what may
> happen to be running as PID 1.
Matthias Urlichs:
Please explain why it should *not* provide these "features". Why
> should every daemon (or its startup script) re-implement the same
> code to put itself in the background, change UIDs, resource-limit
> and security-enhance (private /tmp) itself, when the same thing can
> be implemented once, so that I as a sysadmin (or my puppet script)
> don't have to learn ten separate ways of configuring that?
M. Wanderer was talking about process #1 in his message, M. Urlichs,
which xe made synonymous with "the init system". Your changing that to
be the systemd package, in order to then knock that argument down, is a
strawman. You know, or at least should know, as well as I that one can
centralize the code to do all of those things, and abstract them out of
daemons into a service manager, without that service manager being
process #1. daemontools actually began (version 0.51 dates from July
1997) as exactly a toolset to do this, with things like "svscan" and
"svscanboot" coming a couple of years later. In the intervening years
we have seen daemontools-encore, freedt, s6, perp, runit, and nosh; all
of which can do this. Several of them even come documented with
instructions on how to run them under various process #1 programs.
daemontools, dating from when it did, had instructions for running under
System V init and BSD init. So does perp. runit has a whole load of
instructions at http://smarden.org/runit/useinit.html . s6 has a whole
load of instructions at
http://skarnet.org/software/s6/s6-svscan-not-1.html . The dichotomy
that you present as your challenge, that the choice is between having
process #1 do all of this or having each individual daemon program do
all of this, is a fallacious one, disproven by the existence of toolsets
that allow for avoiding both, for some 17 years now.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/544a6df0.1050...@ntlworld.com
