On 06/08/2015 11:45, tilt! wrote:
> Thing is, init scripts tend to have problems managing services
> that do not offer sufficient commandline interfaces as described
> above

There's a simple reason for that: "init scripts" aren't
"managing services". They can more or less start and stop them,
that's about it - and they're not even doing the starting and
the stopping right.

- Starting ? Sure, it's easy to start a service: run the stuff, and if
it's a daemon, just fork it. Right ? Wrong. When you just spawn the
stuff from your shell, it runs with your shell's environment (open fds,
variables, terminals, so many parameters that are *difficult* to clean
up and really harden). But when you spawn the stuff at boot time, it
runs with the very different environment provided by init. I can't
count how many problem reports I've read in support mailing-lists that
were really hard to track down, but in the end it was just a config
issue because the daemon launching script did not properly sanitize
all its environment, so it didn't give the same results when run by
the admin or when auto-run at boot time.

- Stopping ? Sure, just find a daemon's pid... oh wait, we need to
have it stored somewhere. Hence, .pid files. If you don't know why
.pid files are evil, look it up.

And then you have the other functionality. Restarting, sometimes,
can be lighter than stop + start: maybe there's a whole lot of
config you don't have to do when you're just restarting a daemon -
for instance, if "restart" means "read your config file again",
some daemons support the convention that receiving a SIGHUP should
make them do just that. So "restart" should simply send a SIGHUP
to those, but do stop + start on the others. That's confusing.
There's the "reload" keyword sometimes, but are there any precise
semantics ?
And "status". This is very service-dependent: since there is no
global API, no service manager, scripts will query the daemon's
status in a daemon-specific way. More vagueness again, because
"status" doesn't define exactly what you should say, and the lowest
common denominator is "is it alive?" but even for this basic check,
daemon-specific interfaces are used.

Init scripts just don't cut it, no matter where they come from, no
matter how simple they are or how complex they are. OpenRC is a step
in the right direction, because it provides real support for more
things than sysv-rc, but even it doesn't address all the issues of
init scripts.

What is needed is a *service manager*, a real, full-fledged thing
that doesn't only start and stop services, but does it properly,
without hacks, with the same environment every time, and can tell
you whether a service is alive or not, ready or not, and gives you
a unified interface to interact with it in a simple way. (You still
have to use daemon-specific interfaces for the more complex ways,
because no service manager can unify that.)


> what does SystemD do to address this problem?

It does exactly that. Among the myriad of useless things that systemd
does, it does at least one useful thing: it's a proper *service manager*.
I'm not saying it's correctly designed - it's not: see for instance
http://ewontfix.com/15/ - but it's definitely one of the real, serious
advantages that systemd has over its current alternatives, and it is
important to acknowledge it.

Winning against systemd involves providing better designed alternatives
to the useful parts of what it does, and service management is one of
those: there is a qualitative jump to do here, and messing around with
init scripts is only a quantitative jump and unfortunately isn't going
to accomplish anything if not paired with a serious redesign of how
booting a machine should be done.

That's why I'm currently writing a service manager, and will keep you
guys informed when it's out.

--
Laurent