Including PREFIX/etc/rc.d/* scripts in the system's rcorder for
startup in 6.0-Release
Jose M Rodriguez
josemi at freebsd.jazztel.es
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
> > 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
NETWORKING ... SERVERS network
SERVERS ... DAEMON servers
DAEMON ... LOGIN daemon
LOGIN ... login
> -- Brooks
More information about the freebsd-ports