Including PREFIX/etc/rc.d/* scripts in the system's rcorder for startup in 6.0-Release

Jose M Rodriguez josemi at
Fri Jun 10 06:53:19 GMT 2005

El Viernes, 10 de Junio de 2005 05:56, Brooks Davis escribió:
> On Fri, Jun 10, 2005 at 02:32:34AM +0200, Jose M Rodriguez wrote:
> > El Jueves, 9 de Junio de 2005 23:30, escribió:
> > > Howdy,
> > >
> > > I realize that this is pretty short notice before the release,
> > > but the rc.d team just got a spiffy new volunteer to do the
> > > legwork on this, and so we're going to try to beat the code
> > > freeze/slushie deadline for 6.0. What we've been discussing for
> > > the last few days on the freebsd-rc list is a two-fold approach
> > > in order to avoid needing a flag day to cover this issue.
> > > <snip/>
> >
> > I'm not sure that this is the correct approach.  And even maybe too
> > late in the RELENG_6 timeline.
> >
> > Firts, most ports in real need of rcorder can't wait to localpkg,
> > and use direct rc support breaking $prefix.
> This is easy to fix.  We just modify RC_ORDER to take appropriate
> action based on the version of FreeBSD.  There's plenty of time prior
> to 6.0-RELEASE for that.

Well,  but I think this must begin after RELENG_6 creation.  The actual 
rc is more or less valid.

> > Second, I can easy work scenarios where I can break any logic
> > trying to mix localpkg lex order and rcorder key order.
> The fact that you can break the schem does not imply it would
> actually be broken.  More importantly, a little breaking isn't all
> that serious.

I only point that you may aply the new logic only to ports that 'really 
want it'.

> > If we go to maintain short release cycles, please, delay this to
> > HEAD after RELENG_6.  And only merge it if we go to a safe status
> > before real release.
> The problem is that we have to start some day and we won't be able to
> make a full switch for at least two relases after the initial commit.
> At the very least, I think we should make some attempt at supporting
> rcorder orders scripts within PREFIX/etc/rc.d in 6.0.

I can see the problem, but not the priority.  We're switching from a 
long major release cycle to a short one.  And making a really good '0 
rev' release must be the target.

This is why I point that this must be take only after we are sure.  We 
can test this changes in HEAD after RELENG_6 is tagged and merge from 
current after test before the real release.

> > I still remember latest approach to solve this.
> >
> > I think that the only safe way to take this is make some sort of
> > 'stage' concept into rc (use the SystemV runlevels as a very loose
> > reference).
> >
> > We can use 'stage keys' for implement this.
> >
> > If we have safe localfs access at the end of stage 'n-1', we can do
> > and rcorder for stage 'n' mixing scripts with key 'stage n'
> > in /etc/rc.d/*, /usr/local/etc/rc.d/*, /usr/X11R6/etc/rc.d/* ...
> This requires too much modification of scripts.  There is a quite
> nice proposal on rc@ that simply requires the addition of one script
> to mark the point at which scripts are rescanned.

As I can remember, SystemV runlevels are few, and we implement as last 
part of the concept with the shutdown key.

localpkg is only one case where the problem of rcorder 'linearity' 
shines.  We 'order' the boot at the very begin only.

Allthough 'tagging' only those special scripts maybe easy of implement, 
tagging all the rc system will be a better long term approach.

For clarity, I'm talking about every stript having a key pointing the 
stage (sysinit, ...,multiuser) and do several rcorder keyed scans, 
using predefined macros filled by previuos stage.

rc will to the task for the first stage (sysinit).

The script doing the new keyed scan and invoke of selected scripts must 
be a special end target of the previous stage.

We can implement this adding process of and special %%STAGE%% sed macro 

And we have allready special 'stage' targets like NETWORKING, SERVERS, 

So we can talk, at last of:
		...	NETWORKING	sysinit
SERVERS		...	DAEMON		servers
DAEMON		...	LOGIN		daemon
LOGIN		...			login

> -- Brooks


More information about the freebsd-ports mailing list