svn commit: r204759 - in head: etc/defaults etc/rc.d share/man/man5

[Doug Barton]

On 3/6/2010 7:25 AM, Alexander Leidinger wrote:
> On Fri, 5 Mar 2010 21:18:00 +0000 (UTC) Doug Barton<dougb at FreeBSD.org>
> wrote:
>
>> On Fri, 5 Mar 2010, Alexander Leidinger wrote:
>>
>>> Author: netchild
>>> Date: Fri Mar  5 14:34:33 2010
>>> New Revision: 204759
>>> URL: http://svn.freebsd.org/changeset/base/204759
>>
>> I've got no comments on the jail-related stuff given that my
>> knowledge of jails is almost non-existent. However I wish you had run
>> your diff past freebsd-rc@ since if you had I (or someone else) could
>> have let you know that the attached patch is a much cleaner way of
>> implementing the bit about conditionalizing "parallel" execution
>> (which, to the extent I understand the problem I agree with your
>> solution of only doing it at when starting, FWIW).
>>
>> In general we try to avoid having any code in rc.d scripts run
>> unconditionally. In this case it's harmless (although every cpu cycle
>> counts) but in other cases it can cause problems, which is why as a
>> general rule it's safer to avoid it altogether.
>
> I assume your version covers onestart, forcestart faststart and start
> (I can imagine situations where a prestart should be different from a
> preforcestart, but I doubt we differentiate in the code).

The label to start is stripped in rc.subr (and a variable is set to 
indicate that it was present) before we get to processing start_precmd.

> The reason why I chose the case was, that forcestart and onestart are
> more interactive options. I could imagine that someone tells in the
> future that it may be better to ignore the jail_parallel_start in those
> cases. Can the one/force part be detected in the prestart?

It could (by testing for the variable) but I would be resistant to the 
idea of overloading it like that. It's hard enough to get people to 
understand onestart as it is, I don't want to confuse them by having it 
do "magic" for one particular service.

> The trick with command_args is neat, but it is a pitfall in case
> someone wants to use it in the future. Wouldn't it be better to add the
> ampersand to it instead of letting the ampersand replace the value?

Yes, obviously if someone wants to use command_args for an additional 
purpose down the road changes will have to be made. It's not in use atm 
however, so IMO simpler is better.

> Whatever your answers are, feel free to change what you want to change
> (as long as the feature remains... my main concern is to solve the bugs,
> not how to solve them).

Okey dokey, thanks. :)


Doug

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/