Simon Hobson <linux@???> writes:
> 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.

That's a LSB invention. It's a grotesque travesty as it uses 'magic
comments' to embed a declarative mini programming language in an init
script which is only ever used when modifying the runlevel
configuration. Comments are supposed to be used for relatively short,
free-style documentation embedded in code, not for interpretation by
programs.

> - A ". include" to pull in some standard functions - makes sense, no
> point everyone building their own wheel.

Insofar these functions are generally useful, ie, not just carp like
"print a RED message", they ought to become proper programs which could
then be used in init scripts or elsewhere.

> - Check for, and if found, load a config file - eg
> /etc/default/${service}

TOCTOU race. Running

[ -r /etc/default/sendmail ] && . /etc/default/sendmail

doesn't mean /etc/default/sendmail will still be available when the
source command is executed. Since the shell is (for the sendmail init
script) running without -e at this point, the test can just be dropped.

> - Start/Stop/whatever the service

Possibly including "re-implement every sendmail command a couple of
times" (I'm not joking) in the script plus all kinds of more or less
useless one-off actions, eg, 'check that the required directories are
available' (package should create these on install and if a user deletes
them, stuff is going to break --- let his blood be on his hands, not the
code supposed to wuerg (German for 'choke') around that on my system),
or "update the configuration" (admin's supposed to do that when it was
changed).

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

It's another TOCTOU race, ie, at best, it serves no purpose (trying to
run a program which doesn't exist will fail, anyway), at worst, it's
buggy.

[...]

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

One of the more bizarre arguments in favour of systemd is that most of
the crap code is now invisible :->. But it will aditionally acquire all
kinds of "test that the sea is of the right pink" code hacked together
as Bourne shell code because that's the most thoughtless approach for
accomplishing anything[*].

[*] Insofar systemd doesn't already allow executing embedded /bin/sh
code, someone will sooner or later at magic comments enabling that :->>.