[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: piece of mind

 ❦ 24 octobre 2014 16:19 +0100, Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.com> :

> 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.

All of them are relying on the fact that the monitored process won't
fork. They are therefore not able to handle readiness and
dependencies. Monitoring a PID without active pooling once it has
escaped with a fork _requires_ to be PID 1 (and this is still true with
PID namespaces).
printk("??? No FDIV bug? Lucky you...\n");
	2.2.16 /usr/src/linux/include/asm-i386/bugs.h

Attachment: signature.asc
Description: PGP signature

Reply to: