rc.subr exits prematurely

[Oliver Eikemeier]

Peter Pentchev wrote:

> On Tue, Jul 27, 2004 at 07:34:26PM +0300, Mike Makonnen wrote:
>> On Tue, Jul 27, 2004 at 03:37:12PM +0300, Peter Pentchev wrote:
>>> Hi,
>>>
>>> With the recent changes to rc.subr so that it executes port startup 
>>> scripts
>>> in the same shell instead of in a subshell, another problem has come 
>>> up.
>>> For the scripts which record a PID file, a check is made on startup 
>>> and on
>>> shutdown for the PID file's existence, and if it fails, rc.subr 
>>> exits, which
>>> prevents the rest of the scripts from being executed.  Attached is a 
>>> quick
>>> patch which works around this problem, but may introduce others - I'm 
>>> not
>>> quite sure I understand all of rc.subr's internal workings :)

Thanks for bringing this up.

>> The brokeness is in the port startup script. One of the things ports
>> scripts need to do is install the script without a .sh suffix, so that
>> it does not get executed in the parent shell, and instead in a 
>> subshell.
>>
>> The only things that should get executed in the same shell are scripts
>> like rc.d/rcconf.sh, which is there to load the contents of rc.conf.
>
> Okay, so rc scripts that expect to be called in a subshell should be
> named without the '.sh' suffix.  What does this mean for 4.x though,
> where only scripts *with* the '.sh' suffix are ever executed?  Should
> the ports provide differently-named scripts for 4.x and 5.x (or rather,
> for OSVERSION's before and after the rc.subr overhaul)?

I have a patch to bsd.port.mk which does this. We have to think about 
whether we are happy with it (since -CURRENTs before the change won't be 
able to use packages build on machines after the change), but I guess 
this would be the proper way to handle things. Packages installing `.sh' 
startup script should be treated as being not rcNG aware, wether they 
use some part of the rc.subr structure or not. This will ease upgrading, 
and I believe sourcing ports startup scripts instead of executing them 
in a subshell is not a vastly useful feature and shouldn't be possible.

-Oliver