Use of rcorder for local rc.d/*.sh scripts

J.R. Oldroyd fbsd at opal.com
Tue Jun 7 00:14:59 GMT 2005


On Jun 06, 16:54, Brooks Davis wrote:
> 
> This isn't feasable in the general case with current infrastructure.
> The problem is that you need to make it up to mountcritremote before you
> have any assurance that /usr/local/etc exists.
> 
> Ports contains a work around that allows port to install script in
> /etc/rc.d if they truly need to appear before localpkg.  Such ports
> generally still need to have scripts that run after mountcritlocal and
> won't work on systems where /usr/local is remote unless it is on /.
> 
> From the perspective of someone who works on the diskless scripts, I
> think that sorting scripts in localpkg and using this hack is a decent
> comprimise.
> 
> Another note, this decision will need to be discussed with ports@ since
> there are a lot of scripts in ${LOCALBASE}/rc.d.  There's also at least
> one binary (postfix).  I'd like to see this change happen, but there are
> a lot of issues to work out.
> 

The solution for that would be to:
	- rcorder the /etc/rc.d scripts
	- execute the scripts up to mountcritlocal and a dummy script
	  that has a "PROVIDE: MOUNTCRITLOCAL" or similar
	- rerun rcorder on the complete script list (including the
	  locals)
	- execute the list again, this time skipping over any in
	  /etc/rc.d before the MOUNTCRITLOCAL is reached (since they
	  were done before)

I don't know if that's getting too complicated.  I have to say I
prefer to keep things simple.

I also looked at /etc/rc.subr:run_rc_script and discovered that it
handles "foo" and "foo.sh" differently.  "foo", if executable, is run
in a subshell, whereas "foo.sh" is sourced into the current shell.
I suspect we don't want all the local rc foo.sh scripts sourcing into
the /etc/rc shell.  I.e., to make a change like this, all local rc
scripts would need to be renamed as well as having rcorder tags
added if not already there.

I currently use the hack to localpkg which I originally suggested.
I needed it because several existing ports fail to start without it
and that change does fix the problem.

	-jr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 390 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20050606/d6b105f6/attachment.bin


More information about the freebsd-rc mailing list