❦ 24 octobre 2014 16:19 +0100, Jonathan de Boyne Pollard <j.deboynepollard-newsgro...@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
signature.asc
Description: PGP signature
