RE: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]

[Mike Edenfield]

> From: Walter Dnes [mailto:waltdnes@××××××××.org]
> Sent: Thursday, March 22, 2012 5:14 PM

> On Wed, Mar 21, 2012 at 09:35:55PM -0400, Michael Mol wrote
>
> > What we're talking about with systemd vs openrc, and things like ssh'd
> > first-time initialization is all within the realm of responsibility of
> > the packager. It's a shift in the way the distribution itself works.
> > We're not talking about a scenario where you shunt things upstream, so
> > the whole "your position would have rejected Linux" angle is a red
> > herring.
>
>   This is a frustrating game of whack-a-mole.  Person A comes up with a
> position, I rebut it, and then person B comes up with a different
position, and
> I have to rebut it..  There have been people in this thread who have said
that
> the program best knows what it needs, and should handle its own
> initialization.  That was what I was replying to.
> I'll reply to your position now.

You know the old adage, if you ask 5 geeks a question you get 6 different
answers.

This whole discussion is somewhat surreal to me, when taken in conjunction
with the other heated debate we just finished having:

* udev is evil and horrible because it's trying to do too much and is too
complex.
* system is evil and horrible because it isn't doing enough and is too
simple.

And I'm pretty I've seen at least one person making both arguments
simultaneously.

> > Why does that spawned process have to be sshd? Why can't it be some
> > shell script which does the one-time checks, and then launches sshd
> > itself?
>
>   So instead of the initscript doing the checking+setup and launching the
> service, it launches a a second script... which does the
> checking+setup and launches the service <FACEPALM>.  See my post with
> the joke of digging a second hole to dump the dirt from the first hole
into.
> Instead of one script, we now have two scripts.  This is *NOT*
simplification.

It works fine for mysql, or postfix, or apache, or any of the dozens of
other programs that have helper scripts whose sole purposes is to act as an
entry point to starting up the actual service. It's a common and
well-accepted way of performing required initialization on startup. I don't
see why sshd has to be special here. 

> > Why does that shell script need to be distributed as part of the init
> > system's package, and not part of the package associated with the
> > service?
>
>   I don't understand what you're arguing here.  *THE INITSCRIPT IS OWNED
BY
> THE SERVICE PACKAGE*, not by the init package.  E.g. net-misc/openssh, not
> sys-apps/openrc.

You are absolutely correct; the discussion of who "owns" the init script is
completely tangential to the system vs openrc argument; in both cases, the
required startup files will be provided by the package maintainer and
installed by the ebuild, not by the rc system. I think the confusion may
have started way back when Canek tried to compare the "simplicity" of
sshd.service to the "complexity" of /etc/init.d/sshd. That's the unfair,
apples-to-oranges comparison that triggered this entire debate.

The part that's been lost here is that system doesn't run init scripts(*);
it launches configured services. These are *not* shell scripts; they are
ini-file-like things that define parameters, much like xinetd's
configuration files. Of course, I don't see why this is a problem: configure
system to launch sshd's init script, which keeps doing the same thing it
always has been doing. This is why the comparison between systemd's service
config and openrc's script is unfair. You /cannot/ get rid of the complexity
of /etc/init.d/sshd, you can only make it so that openrc and systemd can
*both* take advantage of that complexity when starting sshd. That may, of
course, require the package maintainer to provide 3 items instead of one: an
openrc init script, a systemd service description, and an rc-agnostic helper
script, in order to be fully systemd-compatible. In the meantime, the
systemd package maintainer will likely be forced to provide some kind of
compatibility shims to run existing openrc scripts that have not yet been
refactored, but that's the cost of choice.

It may already do this, I don't know. I have not yet installed systemd
anywhere but I am curious enough to try it on my laptop. So I will be that
much more informed in the near future :)

(*) As I understand it, systemd *can* run SysV-style init scripts, but
Gentoo's startup scripts are too dependent on openrc-supplied logic to be
reusable in any meaningful sense. 
--Mike