svn commit: r332773 - head/etc/rc.d

[Kyle Evans]

On Thu, Apr 19, 2018 at 10:40 AM, Rodney W. Grimes
<freebsd at pdx.rh.cn85.dnsmgr.net> wrote:
>> On Thu, Apr 19, 2018 at 10:21 AM, Kyle Evans <kevans at freebsd.org> wrote:
>> > On Thu, Apr 19, 2018 at 10:19 AM, Warner Losh <imp at bsdimp.com> wrote:
>> >>
>> >>
>> >> On Thu, Apr 19, 2018 at 9:17 AM, Kyle Evans <kevans at freebsd.org> wrote:
>> >>>
>> >>> On Thu, Apr 19, 2018 at 10:16 AM, Rodney W. Grimes
>> >>> <freebsd at pdx.rh.cn85.dnsmgr.net> wrote:
>> >>> >> Author: kevans
>> >>> >> Date: Thu Apr 19 15:02:53 2018
>> >>> >> New Revision: 332773
>> >>> >> URL: https://svnweb.freebsd.org/changeset/base/332773
>> >>> >>
>> >>> >> Log:
>> >>> >>   Fix ddb rc script
>> >>> >>
>> >>> >>   r288291 added a call to limits(1), which isn't available before
>> >>> >> partitions
>> >>> >>   are mounted. This broke the ddb rc script, which does not provide its
>> >>> >> own
>> >>> >>   start_cmd.
>> >>> >>
>> >>> >>   Alleviate the situation here by providing a start_cmd. We still have
>> >>> >> other
>> >>> >>   problems with diskless setups that need to be considered, but this is
>> >>> >> a
>> >>> >>   start.
>> >>> >
>> >>> > Thanks,
>> >>> > Also didn't cy identify a second one of these?
>> >>> > Or am I confusing yet another issue?
>> >>> >
>> >>>
>> >>> He identified a second early script that didn't specify start_cmd, but
>> >>> it was a non-issue because it's invoked independently of rc.subr.
>> >>
>> >>
>> >> One would think that it shouldn't invoke limits at all if foo_limits= wasn't
>> >> specified... Would make the feature much less invasive.
>
> I agree.  This should be implemented,
> if it isn't already working that way.
>
>> >>
>> >
>> > foo_limits was introduced long after the initial invocation, which was
>> > introduced to enforce consistent limits of daemons run from rc.subr.
>> > Not doing this due to the lack of foo_flags would certainly kill the
>> > original intent, I'm afraid.
>>
>> I do wonder if some kind of kenv var or something would be appropriate
>> to disable this whole mess for some setups that it just clearly won't
>> work in, but maybe that's a terrible thought.
>
> I think you miss understood Warner.  He is saying that if there is no
> rc var *_limits there should be no invocation of limits(1) at all,
> making much of this whole mess for many of us a NOP.

No, I understood that perfectly... the *_limits rc var was introduced
much later just so one can add extra flags to this limits(1)
invocation. This would be counter-productive to the original intention
of the limits(1) invocation, which had no concept of foo_limits until
lately and was intended to just generally apply to all rc scripts
without a bunch of redundant crud in every rc script that it can apply
to.

> I actually believe that is how the code already works, but not sure.

Negative, as I've already mentioned a couple of times... limits(1) is
applied basically unconditionally.