> I may not understand correctly the framework, but not stopping on
> error for a script in rc.d/ not ending in ".sh" is a feature.

...huh?  If a script is one for which ignoring errors is appropriate,
it's perfectly capable of doing so itself.  How is it a feature to
silently ignore errors if the name doesn't happen to end in .sh (which
certainly doesn't say "pay attention to errors" to *me*, at least).

> To "fault", a script must end in ".sh".

Where is this documented, and what is the connection betwee ".sh" and
"is capable of faulting autoboot and going to single-user"?

> Since---I was responsible for a thread about the rc.d/ handling last
> week---every kind of scripts, now, end in rc.d/, that is not only
> system provided (and tested) scripts are here but third parties and
> perhaps suboptimal, aborting on any error would be a bad idea, since
> user level daemons are not critical and may be more easily fixed in
> not single user mode (remote connexion for example).

I have zero inclination to coddle broken startup scripts.  If the
script happens to be one for starting a daemon (counterexamples might
be fsck, mixerctl, and savecore, to name just three), and this daemon
happens to be noncritical for operation of the host (something neither
you nor I can tell, unless the machine be one of ours), this might make
some sense.  But that fails in just too many cases, and cannot be done
right without help from the machine's admin.

What would make some sense would be to use the dependency information
embedded in the scripts - the stuff used by rcorder - to disable
anything depending on the failed script.  This means there needs to be
some kind of "go multiuser" script, or pseudo-script, which can be made
to depend on anything considered critical for operation....

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B