RHAT bug? /etc/init.d/functions:daemon()

[Bill McGonigle]

On Feb 1, 2006, at 13:30, Ben Scott wrote:

>> I didn't say you wouldn't want to use any modules, I said you don't
>> want every module known to man to be used.
>
>   But then someone has to decide which modules are appropriate and
> which are not.  I think the question of deciding which modules are
> "considered useful" is subjective and not really possible to answer
> correctly.

It's the job of the distribution.  They make the same decisions about 
which packages to include.  Some I agree with, some I don't.  Choice is 
good.

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

>> The perl binary for a distribution would statically link in the 
>> modules ...
>
>   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.

>   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.  I wouldn't use 
such a distribution.  You can do the same thing with bash scripts.  
Smart people don't.

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.

>   Hell, let's just symlink /sbin/init to emacs, and do everything in
> Emacs LISP.  ;-)

Paul will back you on this.

>  Like I said, I rather feel that if Perl would help that much, you're
> not writing an initscript, you're writing a full-blown program.
> initscripts aren't supposed to be big, complicated things.  They're
> supposed to start and stop services.

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.  
Sometimes when you start stuff you need to check for error codes, error 
messages and successes.  How many init.d scripts have you seen that 
print [OK] when the process has segfaulted or [FAILED] when it's 
actually worked?  I see this all the time.  I propose that if bash had 
good, easy text processing many more programmers would write good init 
scripts that actually worked.  Having a system full of half-working 
init scripts shouldn't be acceptable.

>   "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.   Punchcard 
init scripts then?

>  I think you've caught the Microsoft mentality.  Features, features,
> features!  "Hey, let's embed an ANSI-compliant C compiler into our web
> browser, a 3D video game into our spreadsheet, and a spell checker in
> our backup software!"  (Extra points for knowing which one of those
> actually happened.)

Hey, no need for slander. ;)  If having an easy to use, reliable modern 
init system is a feature, I'll wear the label.

It's worth noting Apple has ditched the whole lot and gone with launchd 
which is open source.   So this might be a stupid old-farts debate in 
the end.

-Bill
-----
Bill McGonigle, Owner           Work: 603.448.4440
BFC Computing, LLC              Home: 603.448.1668
bill at bfccomputing.com           Cell: 603.252.2606
http://www.bfccomputing.com/    Page: 603.442.1833
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf