Laurent Bercot <ska-devel@???> writes:

> 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.

That's all nice and dandy but it all boils down to 'the code executed by
the init script was deficient in some way'.

[...]

> 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.

But that's something different. Using inetd as simple, well-known
example, if I just changed /etc/inetd.conf, I want to daemon to reread
it and reconfigure itself accordingly to avoid interrupting unrelated
services but in case its on rampage in an endless loop, I want to get
rid of the current process and start a new instance. 'SIGHUP' is just a
random convention dating back to the times when signals where the only
kind of IPC supported by UNIX(*) and the signal was basically hijacked
because a 'daemon process' shouldn't ever receive it for some other
reason. It's not universally supported and not all daemons are so simple
that "reread the config file" is the only means of controlling them at
run time. Eg, someone might want to ask bind to reload a specific zone.

Runtime control of a long running process is a task dependent job. And
since init scripts are task-agnostic, they cannot (sensibly) provide
it.

[...]

> Init scripts just don't cut it, no matter where they come from, no
> matter how simple they are or how complex they are.

[...]

> 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.)

Service management is a more complex task than

[nohup] /usr/sbin/ochsenfrosch >>log 2>&1 &

(although this already gets one rather far) and moreover, it's comprised
of both generic and task-specific jobs and it's sensible to decouple
these two: Let the applications process deal with its problems and
handle the generic issues with other code. Further, the runlevel/ init
script mechanisms and conventions address only a part of the generic
problems services management involves. But "X can't be used" is not
something which follows from "I need feature beyond those provided by
X".

>> 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*.

Is it? Or is it an extremely incomplete, ad hoc designed programming
language with a service manager and a truckload of other potentially
useful stuff attached to it in order to encourage people to swallow the
language?

[...]

> 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.

'Winning' against systemd will require getting support of a
commerically more potent company than RedHat and SuSE combined and one
willing to sink a sizable amount of money into the task. And that's only
a part of the solution because you'll also have to be on the lookout for
senior developers whose surnames match [psk][hoi], otherwise, you might
just end up getting the same thing with a different kind of lipstick put
onto its face.

But 'booting the machine' is a much simpler task and it can be solved
within the existing framework by incrementally adding the missing
bits. Over time, this may end up replacing all of it (while I maintain a
sysvinit fork because that was the path of least resistance for getting
some features I needed, I could easily miss a sizable part of the
inherited code, although actually getting rid of it isn't worth the
effort right now), however, this remains to be seen: Starting from the
presumption that this will turn out to be necessary is a guess.