[prev in list] [next in list] [prev in thread] [next in thread] 

List:       debian-devel
Subject:    Re: Re: piece of mind
From:       Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups () NTLWorld ! com>
Date:       2014-10-24 15:19:12
Message-ID: 544A6DF0.1050306 () NTLWorld ! com
[Download RAW message or body]

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: https://lists.debian.org/544A6DF0.1050306@NTLWorld.com

[prev in list] [next in list] [prev in thread] [next in thread]