Rainer Weikusat <rainerweikusat@???> wrote:

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

Presumably you have a suitable alternative, that's "backwards compatible", admin accessible, and makes sense to others ?


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

Well since (I suspect) most of them don't have much (if any) applicability outside of init scripts, I'd say a library of common functions as an include makes sense. Do you also object to libraries of common functions in other languages ?

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

Strictly speaking, yes you are correct. However, unless there is something seriously wrong with the system then /etc/default/${program} isn't going to be appearing or disappearing at this time. However, as it is an optional file for many programs, it does (IMO) make sense to handle whether it is there or not, rather than "just fail" with an ugly message.

This is one area where I think we'll need to agree to disagree.
I'm of the school that believes programs should handle "reasonably foreseeable" situations gracefully rather than spitting out whatever error message the underlying language uses which may or may not make sense to to the user/admin. I think we've all seen errors along the lines of "flurble error at line 2057" which mean nothing whatsoever to the user - but on calling the helpdesk they tell you "oh yes, your flibble config file is missing a blurble definition". In that sort of case, the error message should be more like "no blurble definition found in config".

Yes I suppose you could just do ". /etc/default/sendmail 2> /dev/null" but that then means you also throw away real error messages that might happen, rather than simply and gracefully handling a foreseeable configuration state.


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

There I admit we're getting into "shouldn't happen anyway, so don't bother testing for it" territory. The most likely scenario I can think of is that the user/admin modified the file and so the packaging tools didn't remove it - but the symlinks from /etc/rcn.d would have been removed. I "wouldn't be upset" if that test was omitted.

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

I agree.




Rainer Weikusat <rainerweikusat@???> wrote:

> The sendmail init scripts is 1340 lines long, 901 of which contain code.

I wasn't aware of that, I am inclined to agree that it sounds "way too much"

> In contrast to this, "about 40 lines" is entirely reasonable.

Well I've just looked on one of my systems, and picked one script - ntp
70 lines
Looking at the code I don't believe it's excessive.

- The aforementioned magic comments. Yes it's a hack, but got a better idea ?
- Set some paths for use later - IMO this is "a good thing", much better than scattering them throughout the code.
- Check for the presence of a couple of optional config files, and load them if present. One of these is from another package that may or may not be installed so it's completely reasonable to see if it's there before trying to use it.

- Define some stuff around having a lockfile between ntp and ntpdate. I do wonder how ${other_init_system} handles this ?

- And then the case statement that handles start|stop|...

All in all, I don't consider anything in there excessive. There's some that could be trimmed - that's a matter of style - but nothing I can see that re-invents the wheel.

Using the case statement is, IMO, a good thing. It gives *complete* flexibility in what the script does, and in a way that's easily understood by most people.
Now, taking the example you gave in another message of how few lines you needed ... does that actually handle an arbitrary set of actions ? If so, how is that handled ?


TBH, I don't think we're arguing against each other all that much. I don't think your complaint is so much against the use of scripts, but against bloated <anything>.
IMO, using scripts like this is a good thing, it gives the flexibility to do pretty much anything, without loads of crap getting obscured into a mess of C.

As a thought, have you submitted a "fixed" Sendmail script to the Sendmail project ?