Re: Init system deba{te|cle}
On Tuesday, October 29, 2013 05:48:20 PM Jonathan Dowland wrote:
> On Tue, Oct 29, 2013 at 04:55:44PM -0400, John wrote:
> > Could someone who has been following the giant fuss on -devel over
> > init systems explain why there's such a sense of dire urgency?
>
> I think it's largely driven by frustration over how bipartisan the
> discussion is and how long it has been going on (it has been repeating
> over and over for years), combined with a desire on the part of most
> folks for Debian to move to *some* modern init system (the debate
> being, which).
I imagine part of the debate includes the fact that systemd integrates all
kinds of systems and subsystems in an attempt to become the do-all and end-all
of services control. This effort moves far away from the old UNIX concept of
'do one thing and do it well'. Were I to be unkind, I would opine that systemd
is an attempt to make Linux more like Windows, where everything has tentacles
everywhere.
I think a 'next-gen' sysvinit could be developed--from sysvinit--that would
satisfy most requirements of a services monitor, and continue to do what
sysvinit was intended to do in the first place: start daemons and keep them
running as best as possible without creating all manner of interdependencies.
Were one to look, on would see that init is really only used for two purposes
today: (1) to restart gettys and (2) to inherit processes and reap zombies. It
isn't used to start, maintain and stop daemons; when a daemon dies, it can be
days before its absence is noticed.
So who is up to extend sysvinit to 16-32 run levels with an 'init tree' (or
trees) instead of the current 'init table'? Extend it to follow its original
purpose: start, stop and maintain daemons and services. Allow daemons to be
started in parallel (up to the count of available CPUs), but add checkpoints
to the tree that pause until pending parallel startups are complete before
continuing to spawn more daemons (i.e., handle startup dependencies). And
design it so that the tree is human-readable, so that it doesn't require a
whole new suite of incomprehensible programs to (re)start and stop daemons.
Design this 'next-gen' init to use the existing start/stop scripts in
/etc/init.d. It's possible. It's doable. It would require learning a 'new way'
but would be far less invasive than current alternatives.
N
Reply to: