On 07/08/2015 00:09, Rainer Weikusat wrote:
> Since this is maybe/ likely a bit harsh

Not harsh, just unwilling to accept that I'm actually your ally and
not your enemy.

I'm not trying to replace Unix, because Unix is not broken - at least,
not as far as system startup is concerned. There *are* broken things
in Unix, but that's a whole other enchilada that I won't have time to
address in the next 2 or 3 lifetimes.

I'm trying to replace *systemd*, with something that embraces Unix
much, much more.

sysvinit or sysvrc init scripts don't define Unix. Trying to do better
than them is not replacing Unix, it's trying to do things right. Now is
the time to do things right, because if we don't, systemd is going to
take over, for good. I don't want that, and since you're here, I don't
think you want that, either.


> If you're convinced that "rip and replace" is the only
> viable option then I won't claim that you're wrong because I really
> don't know. However, until I hit a technical obstacle, I won't be
> convinced that the existing system can't be fixed (I acknowledge almost
> all defects you mentioned) and this is based on being familiar (as in 'I
> wrote the code') with both approaches.

Fine. I'm okay with the burden of proof. Let's take a simple example and
see how deep we have to dig to make it work.

You have 3 longrun services, A, B and C.
A and C can take a long time to start and be ready, because they access
some network server that can be slow, or even fail. But they don't depend
on anything else than this network server.
B depends on A. It does not contact the network server, but it consumes
non-negligible resources on the local machine at startup time.

Your objective is to reach the state where A, B and C are all up and
ready as quickly and reliably as possible. How do you proceed ?

Serially ? "A start && B start ; C start"
Not good: you add A's and C's latencies.

Parallely ? "A start & B start & C start"
Not good: B can be scheduled to start before A, and will crash.

Using a supervision system to make sure all the services will eventually
be up ? "s6-svc -u /service/A ; s6-svc -u /service/B ; s6-svc -u /service/C"
Better, but still not optimal: if B crashes because A is not up yet, it
will be restarted, and it's annoying because it's hogging important resources
every time it attempts to start.

You need a dependency manager.

"rc A+B+C"
Much better. Except there's no such thing yet. The closest we have is
OpenRC, and for now it's serial: you'll eat the added latencies for A and C
just like in the naive serial approach. Ouch.
ISTR there are plans to make OpenRC go parallel at some point. Let's
assume it is parallel already. What do you do if A crashes because the
network server is down ?

You also need a supervision system, coupled with the dependency manager.
The OpenRC folks have realized this, and you can use a flag to have your
service auto-restarted. There's also some early support for s6 integration,
which I won't deny is flattering, but I still don't think the design is
right: for instance, there are early daemons you can't supervise.

OK, now, how do you detect that A is ready and that you can start B ?
Well, you need readiness notification, assuming A supports it. You need
it because you don't want B to crash and restart. And now your rc system
must implement some support for it.

And I haven't even mentioned logging yet.

If you've written init systems, you must have reached that point. I'm
interested in knowing how you solved those issues.

Now, if you try to implement process supervision, dependency management,
readiness notification and state tracking in pure init scripts, well,
gl&hf. That's what sysvrc, with tools like start-stop-daemon or other
horrors, has been trying to do for 10 years, without knowing exactly what
it was that it was trying to do. The result isn't pretty.

Then systemd came and said "hey look! I can do just that, and more, and
you don't have to bother anymore with those horrible sysvrc scripts!"
And what did admins say? YES, PLEASE. And they gobbled up the crap because
it was coated with the sweet, sweet features. (And, yes, with an unhealthy
dose of propaganda and bullshit, but if you dig through the bullshit, you
can find a few things of value.)

I'm saying the same causes will have the same results, and more tweaking
of the init scripts isn't going to accomplish anything without some serious
redesign. It's the easy path; I'm all for the easy path when it can be
taken, but in this case, it's not the right one. The right path is to
provide the sweet, sweet, *needed* features - but to do it the Unix way.


> A social reason, eg, $someone
> pays my bills ($someone =~ /hat/) and that's what I did and you will
> have to eat it aka 'resistance is futile ...' won't do.

You are fighting windmills. This is the Lennart way, it's not mine and
I don't think it is anyone's here. Even if I wanted to, which I don't
and never will, I don't have the power to ram anything down people's
throats.

--
Laurent