On Sat, 4 Jun 2016 00:42:46 +0200
Florian Zieboll <f.zieboll@???> wrote:


> My experience with init systems is mostly limited sysV init (well,
> also busybox and system d). That said, I wonder, what information any
> arbitrary init system would need, that can not be delivered e.g. in a
> simple XML file, packaged with the daemon.

You never, never, NEVER want PID1 to be encumbered with an XML parser.
Unless you're OS/x (launchd). What could *possibly* go wrong?

>
> Seriously, what else besides dependencies on other daemons that have
> to be running and some testing for the existence of certain
> (everything is) files would be necessary to pass to a parser script,
> which could be packaged with the respective init system?
>
> Somewhat stunned,

Hi Florian,

You've taken this discussion deep enough that the definition of "init
system" becomes relevant.

Up until your question, init system discussions have pretty much
divided things into the monolithically entangled April Fools
Architecture systemd, and all other inits, which are fairly sane.

You're going deeper.

I'm going to reveal my bias right now. I think an init system should
look like this:

The author, Rich Felker, contends that PID1 should do nothing but fork
off a shellscript (the rc file) and sit there spinning around handling
signals. The rc file, which is NOT part of PID1, calls the software
that handles process management or process supervision (the latter
being the name we call things that respawn and don't expect the daemon
to put itself in the background).

I've read some of the writings of Laurent Bercot, author of s6 and
s6-rc, and if I understand him right, Laurent doesn't like the Felker
model because if the process handling the rc shellscript dies and
there are no terminals surviving, you're left with a dead machine whose
PID1 is still spinning merrily along. He's right about that, but it's
not a problem I'd personally worry too much about. But then again, I'm
not running a server bringing in $100K revenue a day.

If you're advocating putting an XML parser in something spawned by the
rc shellscript, hey, I'm fine with that. I'd do it differently, but
we're talking minor differences. If you're talking about putting it in
PID1, well, that's why we all deserted systemd: PID1 shouldn't have
that crap.

I personally think that the system of processes having provides and
needs is brilliant. I don't think it's ever been executed well, but the
idea is great. With provides and needs, it's probably pretty easy to
figure out run order, or with the daemontools-inspired process
supervisors, run script dependency checks. I think this is what you
were getting at with the XML idea.

There are two points of view on converting provides and needs to
process order: Fixed, where it's calculated ahead of time and turned
into a process startup order, and on boot, where the process starting
order gets done at boot time. Poettering favors the latter. I prefer the
former so that my boot is guaranteed determinate and I know the process
instantiation order.

Either way, as long as that stuff gets done outside of PID1, I'm happy.

Now I'm going to wander into the realm of pure opinion, and please
understand, I am not, not, NOT suggesting Devuan ever officially
incorporate this...

Regardless of your OS, regardless of your init system, regardless of
your distro, you can really take charge of your computer by moving some
of the process management out of your init system and into a dedicated
process supervisor like daemontools-encore, runit (used as a non-PID1),
and s6. Every process you move out of sysvinit or OpenRC and into
something like s6 is one more 100 line init script you can ignore. It's
one more set of magic order-defining comments you don't need.

Before I ever heard of systemd, I was using daemontools to run some of
my processes, just so I'd know what was under the hood, and I could
work on them. After all, the sysvinit/upstart combination that existed
before systemd wasn't all that understandable.

In the early days of the systemd controversy, I thought I'd just go
with systemd, and one by one remove control of processes from systemd
and give them to daemontools-encore or s6.

You know how old I am? My first car (1959 Plymouth that I bought for
$150) had a flat head 6 engine on which you could do a tune-up in 20
minutes with a pliers, adjustable wrench, an emery board and a gapping
tool. Do you know how NICE that was? I could do almost anything on that
car if it didn't require a lift.

I look in the engine compartment of my Jeep Patriot and know the most
technical thing I'll ever do to it is fill the coolant. Everything's
all interconnected. I like my Jeep's gas mileage and the fact that it
doesn't burn a quart of oil every 50 miles, but man, I miss my Plymouth.

The more you take your process control away from your init and hand it
over to the likes of daemontools-encore, Runit or s6, the more you feel
like your under the hood of a 1959 Plymouth, only this 59 Plymouth DOES
get 2016 gas mileage and performance.

I always feel a lot better when I can singlehandedly fix what goes
wrong with my possessions.

SteveT

Steve Litt
June 2016 featured book: Troubleshooting: Why Bother?
http://www.troubleshooters.com/twb