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

[Kyle Evans]

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.
>>
>
> 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.