databases/postgresql81-server - dangerous init script

[LoN]Kamikaze LoN_Kamikaze at gmx.de
Tue Mar 28 21:54:35 UTC 2006


Brooks Davis wrote:
> On Tue, Mar 28, 2006 at 08:58:49PM +0200, [LoN]Kamikaze wrote:
>> Brooks Davis wrote:
>>> On Tue, Mar 28, 2006 at 08:34:32PM +0200, [LoN]Kamikaze wrote:
>>>> The rc.d script for this port contains a new style script, but follows
>>>> the old naming conventions, which will cause it to be executed directly
>>>> sourced into the boot shell, which is an unnecessary risk, since it
>>>> means that booting will fail if the script exits.
>>> Actually, in this case, the manpage is wrong.  Only scripts in /etc/rc.d
>>> that end in .sh not all scripts ending in .sh are sourced.  That said,
>>> ports should be fixed to install without the .sh suffix so we can eventually
>>> remove the special case (should there be any point.)
>>>
>>> -- Brooks
>>>
>> Well, that's what you get when you trust a manpage (somehow that makes
>> me remember the UNIX Haters Handbook).
>> That leads to the question what sourcing a script into the boot shell
>> gains us that makes it worth the risk?
> 
> It's of limited use.  We initially used it for sourcing rc.conf
> vi /etc/rc.d/rcconf.sh and for supporting /etc/rc.early via
> /etc/rc.d/early.sh.  The rc.conf stuff is now in /etc/rc and I think we
> should just kill off /etc/rc.early support since it's basicly pointless
> (just drop the script in /etc/rc.d with the right variables).
> 
>> Triggering it by a naming convention also looks like a leftover from the
>> old system. Doing this with a KEYWORD would seem more consistent to me
>> and increase the probability that the script author knew what he was doing.
> 
> Doing it with .sh is what lukem (of NetBSD) designed and we've stuck
> with it.  If anything, I'd be inclined to get rid of the feature rather
> than change it.  Triggering with a keyword would add a lot of code and
> overhead to rc.subr.
> 
> -- Brooks
> 

I'd like to see developers not only document the features of their
software, but also what the feature is good for. Especially in such
cases where this is not obvious.
Has anyone ever asked lukem of NetBSD what it is good for?



More information about the freebsd-ports mailing list