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

J.R. Oldroyd fbsd at opal.com
Tue Jun 14 13:47:54 GMT 2005


It seems to me that TWO changes will be needed to make this transition.
The transition modifies the semantics of how files in the local rc.d
dirs are handled.

Right now, local "foo.sh" files are executed in a subshell.

After we're done, we want "foo" to be executed in a subshell and
"foo.sh" to be sourced.  There are possible negative consequences
of sourcing all "foo.sh" files, so two changes will probably be
needed, one now in the short term which adds the rcordering
capability and preserves other semantics, and one later on which
brings all semantics into line.  Something like this:

A. NOW:
	/etc/rc.d	rcordered with "foo" run in subshell and
			"foo.sh" sourced
	local dirs	"foo.sh" run in subshell from localpkg
			in alphabetical order

B. SOON:
	/etc/rc.d	rcordered with "foo" run in subshell and
			"foo.sh" sourced
	local dirs	"[0-9]foo.sh" scripts are run in a subshell
			first, then "[^0-9]foo.sh" and executable
			"[^0-9]foo" scripts run rcordered and run in
			subshells; "foo.xyz" (e.g., ".sample") ignored?
	ACTION required of port maintainers: NONE

C. AT FUTURE FLAGDAY:
	/etc/rc.d+local	rcordered with "foo" run in subshell and
			"foo.sh" sourced; "foo.xyz" files now treated
			as "foo"
	ACTION required of port maintainers:
			- add rcorder tags to all scripts
			- rename "foo.sh" to "foo" unless sourced
			  behavior is desired
			- rename "[0-9]foo.sh" scripts to something
			  more suitable
			- move "foo.xyz" (e.g., ".sample") files
			  elsewhere

My thought is that to oblige port maintainers to make changes in
the short term will be hard.  Give them some time (between points
B. and C. and acceptance of the change will be a lot easier).

So let's provide intermediate rc, rc.subr and localpkg scripts that
may be larger and more complex, but which don't place an immediate
burden on 13,000 port maintainers.  Then provide a final set of
scripts which do.  The intermediate scripts can provide warning
messages that alert that a change may be needed.

	-jr



On Jun 13, 08:52, Brooks Davis wrote:
> On Sun, Jun 12, 2005 at 10:29:45PM -0700, Doug Barton wrote:
> > Brooks Davis wrote:
> > 
> > >I don't like the idea of tagging all the scripts.  First, it makes the
> > >update suck.
> > 
> > rm /etc/rc.d/* ; mergemaster -i
> > 
> > I understand that this mechanism is a little more invasive, but it uses the 
> > existing rc.d framework without adding too much additional code. Also, 
> > using keywords makes this really easy to work around, since keywords are 
> > harmless if they aren't actually invoked.
> 
> I know about this workaround.  It's fine unless you've modified even a
> single script.
> 
> > >Second, that's a lot
> > >places to keep state up to date.  JR's proposal of using a marker script
> > >had the downside of adding slightly more code to /etc/rc, but the
> > >advantage of not having to keep all the files in the right place.
> > 
> > I'm not sure what you mean by "a lot of places to keep state." This is a 
> > one-time modification, and any scripts that we need to add to bootearly are 
> > easily added. The disadvantage to a marker script is that if some other 
> > dependency gets juggled in another script, the marker could run in a 
> > different order. By using keywords we can be 100% sure what will happen in 
> > each phase.
> 
> What I like about the marker script is that dependency changes still
> work.  I don't want to have to figure out every script that needs to
> change if I add "# BEFORE: mountcritremote" to a script or if I change a
> script that previously ran before mountcritremote to run after it.  This
> is the strength of rc.d.  Down the path of adding tags to indiacte
> startup order lies SysV init.  That's not all bad, but I'd like to think
> we chose rc.d over SysV init because it was better not because it was
> less SysV.
> 
> > >The local_startup collector looks pretty good. 
> > 
> > Thanks.
> > 
> > > I'm not 100% how I feel
> > >about the *.sample exception.  On one hand it seems like the safest
> > >thing to do, on the other hand, it's the sort of feature that tends to
> > >hang on forever. 
> > 
> > I would say that's accurate. :) I think that when we get farther down the 
> > road of the conversion (and we can be sure that things won't start 
> > accidentally if the user doesn't put the right things in 
> > /etc/rc.conf[.local]) then we can carp on this more.
> > 
> > >I'd be slightly inclined to complain about .sample
> > >scripts that are executable to try and get people to stop installing
> > >them.  We should almost certainly complain about script that aren't *.sh
> > >that are not executable.  Effectivly those will all be all port bugs.
> > 
> > I agree, but my preference would be that we also hold off on this till 
> > we're further down the road of the transition. I'm flexible on all this 
> > stuff though, let me know what you think.
> 
> I generally prefer to complain early.  The sooner we ship a release that
> gripes, the sooner the users start beating up on port maintiners to make
> the warning go away. :-)  We can't generally drop support for "features"
> until we've warned for a good part of a branch.  I'd like see warnings
> about older scripts by the time 6.x goes production ready.
> 
> -- Brooks
> 
> -- 
> Any statement of the form "X is the one, true Y" is FALSE.
> PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4


-------------- 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/20050614/dda51346/attachment.bin


More information about the freebsd-rc mailing list