init and initscripts (was: RHAT bug?)

Ben Scott dragonhawk at gmail.com
Wed Feb 1 22:43:00 EST 2006


On 2/1/06, Bill McGonigle <bill at bfccomputing.com> wrote:
>>   So now, in addition to having the "Does this platform
>> support Perl in initscripts" question, we have the "Which Perl modules
>> does this platform variant support in an initscript" question.
>
> Right, just like you have to ask the same question about "which
> programs does this distribution include that I can call from an init
> script".

  Hrrrm.  Somewhat.  The "fundamental Unix tools" (for lack of a
better term) are actually pretty standardized in their availability
(grep, sed, awk, cat, cut, sort, uniq, etc.).  But the various
implementer extensions to them are a little harder to rely on.  So
you've got a point.  But I think Perl and it's herd of modules is a
*much* bigger can of worms.  *shrug*

>>   Can you do that with Perl?  I thought modules were basically just
>> Perl include files.
>
> Most modules contain XS code - usually written in C.  On a normal perl
> they're loaded dynamically, but that's not the right way to do
> something that has to run from /bin.

  Actually, on most Linux distros, most things in the root install are
still dynamically linked.

  But I was talking about the Perl module *.pm files.  A lot of the
implementation work is done in pure Perl.  Does Perl have an existing
feature that will let you embed Perl modules and other stuff into a
single "fat binary"?  (I'm more curious than anything else; I'm sure
it could be added with sufficient effort.)

>>   So eventually I'll end up with an initscript that requires a working
>> installation of X, GNOME, a sound server, and Mozilla.  Oh joy.
>
> If you have a moron maintaining your distribution, yes.

  Given that, I think it is a fair statement that all distributions
are maintained by morons.  :-)

> If it were a LiveCD for a PVR maybe that would make sense though.  I'd
> at least be willing to listen to that argument.

  Well, sure, special cases are always the exceptions.  Like the PHP
init script thing for the web-based embedded firewall kit.  Since the
system has one purpose in life, you can make calls like that.  I'm
talking the general-purpose kits (Red Hat, Debian, etc.).

> Yet they can be cumbersome to write in bash, even for those of us who
> know bash.  If you've never said, "gosh, this would be so much easier
> in..." while hacking bash scripts then you get a pass on this one.

  Sure, I've said that.  Tons of times.  That's usually when I switch
to Perl (or C, or whatever).  But I've never said it while building an
initscript!  :-)

> ... many more programmers would write good init
> scripts that actually worked.

  In my experience, the "a better language leads to better
programmers" theory isn't especially true.  Crap code is crap code, no
matter what it's written in.

  Should init scripts be written in Ada?

> Having a system full of half-working init scripts shouldn't be acceptable.

  No argument there, but I think it's unrelated to the implementation language.

>>   "Perfection is achieved not when there is nothing left to add, but
>> when there is nothing left to remove." -- Antoine de Saint-Exupery
>
> "Quoting some dead guy doesn't bolster an argument" - me.

  I think you want: "A witty saying proves nothing." -- Voltaire  ;-)

  And I quoted M. Antoine because I very much agree with the message
of the quote, not because I thought the simple use of a quotation was
a selling point.  I believe the sentiment is correct and true, and
engineers in general could stand to learn a lot from it.  The quote is
simply a rendering of the concept.  Refute the concept if you like. 
Don't get hung up on the quote.  :)

>  Punchcard init scripts then?

  Not the point. The point is that complexity leads to failures, and
in a core thing like an initscript, you want to keep things simple. 
Perl (or Python, or Java, or Visual Basic for that matter) have all
sorts of benefits over bash in the general case, sure.  But I honestly
believe that kind of complexity does not belong in an initscript.

>> I think you've caught the Microsoft mentality.  Features, features,
>> features!
>
> Hey, no need for slander. ;)  If having an easy to use, reliable modern
> init system is a feature, I'll wear the label.

  I find initscripts easy to use.  You've already heard my argument on
reliability.  As for "modern"... well, if that's what you're after,
Unix is not for you.  That's actually Microsoft's argument again. 
"Linux is Unix, and Unix is old, and old stuff is junk."  Personally,
when I see something is still in use after 25 years, I want to look
closer and find out why.  Maybe it's a really good design and worth
learning from.  (Granted, it could just be crap that can't be throw
out for some reason, but the point is that "old" != "bad".)

> It's worth noting Apple has ditched the whole lot and gone with launchd ...

  Wasn't familiar with it.  I just looked it up.  Yet Another daemon
manager/init replacement.  There's gotta be over a dozen out there by
now.  Ho hum.  :)

  One idea I saw pitched once that I liked more was a command called
"needs" (or it might have been "need").  An initscript would start off
with commands like this:

	needs network
	needs dns
	needs whatever

Initscripts also had a way to identify what they provide (I forget if
it was a command or some syntax in a comment (a la chkconfig) or
what).  When entering a runlevel, the system could just run all the
scripts in that directory.  No ordering with numbers in the names was
needed.  When "needs" ran, it would see if the facility was available,
and if not, start it.  So initscripts started their own dependencies. 
Very Unixy.

  For service watchdogging and restarting, a separate utility was
provided.  I forget the name of that, too, but it was basically like
that Perl script you posted, except with more bells and whistles.

-- Ben



More information about the gnhlug-discuss mailing list