svn commit: r331880 - stable/11/etc

[Kyle Evans]

On Mon, Apr 9, 2018 at 9:04 AM, Niclas Zeising
<zeising+freebsd at daemonic.se> wrote:
> On 04/02/18 17:39, Rodney W. Grimes wrote:
>>>
>>> Author: kevans
>>> Date: Mon Apr  2 15:28:48 2018
>>> New Revision: 331880
>>> URL: https://svnweb.freebsd.org/changeset/base/331880
>>>
>>> Log:
>>>    MFC r328331: Support configuring arbitrary limits(1) for any rc.conf
>>> daemon
>>>       Usage is ${name}_limits, and the argument is any flags accepted by
>>>    limits(1), such as `-n 100' (e.g. only allow 100 open files).
>>>
>>> Modified:
>>>    stable/11/etc/rc.subr
>>> Directory Properties:
>>>    stable/11/   (props changed)
>>>
>>> Modified: stable/11/etc/rc.subr
>>>
>>> ==============================================================================
>>> --- stable/11/etc/rc.subr       Mon Apr  2 15:07:41 2018        (r331879)
>>> +++ stable/11/etc/rc.subr       Mon Apr  2 15:28:48 2018        (r331880)
>>> @@ -773,6 +773,8 @@ check_startmsgs()
>>>   #
>>>   #     ${name}_login_class n   Login class to use, else "daemon".
>>>   #
>>> +#      ${name}_limits  n       limits(1) to apply to ${command}.
>>> +#
>>
>>
>> Caution, limits(1) is in /usr/bin, this code can fail if used before
>> /usr is mounted.  (Ie, our rc.initdiskless) is probably broken by
>> this change if a call is made to limits.
>>
>>
>
> Sorry for jumping on this so late.  This is also an issue in CURRENT, and
> has been since at least 2016.
>
> See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206291
>

I kind of like Cy's approach in Comment #7.. scripts that start pretty
early, at least, are bound to trip over all kinds of issues.

I don't think it's a good idea to work around this in rc.subr like his
"relief valve" patch since it'll just create hidden inconsistencies in
some of these things. _limits isn't getting applied, but it's not
obvious that _limits isn't getting applied because we just silently
work around it. Before we know it, we'll be adding something else
that's nice in the general case but not applicable for some of these
earlier bits.

Rod, what are you thoughts on these approaches?