Rainer Weikusat <rainerweikusat@???> wrote:

> The commands which are actually executed via these S- and K-links come
> from individual packages and ultimatively contain whatever the people
> responsible for that considered sensible. Which is usually a pretty
> arbitrary assortment of more or less useless code which accumulated over
> ca 20 years in the course of "whatever, the easiest way to make the
> problem go away is hack some more code into the init script".

My impression from occasionally having to debug some startup issue is that the scripts I see aren't all that bad. I can't speak for other distros as most of my systems are Debian, but they mostly seem to be :
- Some headers to tell utilities what runlevels the service should run at, and dependencies.
- A ". include" to pull in some standard functions - makes sense, no point everyone building their own wheel.
- Check for, and if found, load a config file - eg /etc/default/${service}
- Start/Stop/whatever the service

OK, I've not delved into the functions, but I wouldn't describe the scripts I've worked in as having any quantity of useless code.

I suppose you can argue about things like "test for the executable being present and executable before trying to run it" - is that cruft, or simply sensible defensive programming ?
Similarly, running the program via a "pretty start" function - cruft or simply providing a better user interface ?

> In further twenty years, continuously maintained systemd unit files will
> look exactly like present-day 'init scripts' or end up executing scripts
> which do. And the same is true for any other software maintained using
> this method.

Very likely. Except that with systemd it's going to have a lot obfuscated in C.