Re: login.conf processing by /etc/rc
On Thu, Sep 29, 2016 at 03:33:48PM +0300, Evgeny Grin wrote: > > > On 29.09.2016 13:57, Otto Moerbeek wrote: > > On Thu, Sep 29, 2016 at 11:45:21AM +0300, Evgeny Grin wrote: > >> May be it also worth to mention in /etc/login.conf comments, that if > >> both '-max' and '-cur' were set for "default" class, it's required to > >> override explicitly both values in other classes, because 'openfiles' > >> (without suffix) setting will be ineffective. > > > > I don't think that is true in general. That only holds for daemon. > > > > Other cases are handled by login. > > OK, let's add comment at least for "daemon". > > And it's not clear from man pages: what will happen if 'openfiles-max' > and 'openfiles-cur' set for "default" class and 'openfiles' set for > "staff" class. Which value will be prioritized? > And vice versa - if 'openfiles' set for "default" class and > 'openfiles-max', 'openfiles-cur' set for "staff" class, which value will > be effective? > > 'openfiles' used only as example - it can be any of cputime, filesize, > datasize, stacksize, coredumpsize, memoryuse, memorylocked and maxproc. > > Is it possible to get right value with this API? > http://man.openbsd.org/login_cap.3 > > -- > Best Wishes, > Evgeny Grin Th actual function (gsetrl()) to compute the resource limits is not exported from libc. If a name without a suffix is specified before any more specifc (-min or -max) name in the fully expanded record any -max or -min value will be ignored. getcap() does not implement this logic. -Otto
Re: login.conf processing by /etc/rc
On 29.09.2016 13:57, Otto Moerbeek wrote: > On Thu, Sep 29, 2016 at 11:45:21AM +0300, Evgeny Grin wrote: >> May be it also worth to mention in /etc/login.conf comments, that if >> both '-max' and '-cur' were set for "default" class, it's required to >> override explicitly both values in other classes, because 'openfiles' >> (without suffix) setting will be ineffective. > > I don't think that is true in general. That only holds for daemon. > > Other cases are handled by login. OK, let's add comment at least for "daemon". And it's not clear from man pages: what will happen if 'openfiles-max' and 'openfiles-cur' set for "default" class and 'openfiles' set for "staff" class. Which value will be prioritized? And vice versa - if 'openfiles' set for "default" class and 'openfiles-max', 'openfiles-cur' set for "staff" class, which value will be effective? 'openfiles' used only as example - it can be any of cputime, filesize, datasize, stacksize, coredumpsize, memoryuse, memorylocked and maxproc. Is it possible to get right value with this API? http://man.openbsd.org/login_cap.3 -- Best Wishes, Evgeny Grin
Re: login.conf processing by /etc/rc
On 2016/09/29 12:57, Otto Moerbeek wrote: > On Thu, Sep 29, 2016 at 11:45:21AM +0300, Evgeny Grin wrote: > > > > May be it also worth to mention in /etc/login.conf comments, that if > > both '-max' and '-cur' were set for "default" class, it's required to > > override explicitly both values in other classes, because 'openfiles' > > (without suffix) setting will be ineffective. > > I don't think that is true in general. That only holds for daemon. > > Other cases are handled by login. I've been bitten by this (with daemon) more times than I like to admit..
Re: login.conf processing by /etc/rc
On Thu, Sep 29, 2016 at 11:45:21AM +0300, Evgeny Grin wrote:
>
>
> On 29.09.2016 8:08, Otto Moerbeek wrote:
> > On Thu, Sep 29, 2016 at 12:10:47AM +0300, Evgeny Grin wrote:
> >
> >> Hi!
> >>
> >> I configured freshly installed OpenBSD 6.0-release with
> >>
> >> kern.maxfiles=131072
> >>
> >> in /etc/sysctl.conf
> >> and
> >>
> >> :openfiles-max=40960:openfiles-cur=40960:
> >>
> >> for daemon in /etc/login.conf
> >>
> >> And at each boot I see message:
> >> kern.maxfiles: 7030 -> 131072
> >> /etc/rc: ulimit: bad -n limit: Invalid argument
> >>
> >> I looked at /etc/rc and found that script at first step call 'ulimit -S
> >> -n ' for value found for '-cur' and at second step call 'ulimit -H -n '
> >> for value found for '-max'. That is incorrect as soft limit can't be set
> >> to higher value than hard limit. Moreover, I can't just use
> >> ":openfiles=40960:" for daemon class because "default" class has both
> >> "-max" and "-cur" values - as result: at first step "40960" used for
> >> both hard and soft limit, but immediately lowered by using "-cur" and
> >> "-max" values from "default" class (getcap return them for "daemon"
> >> class as well).
> >>
> >> As current workaround I use
> >>
> >> :openfiles=40960:openfiles-max=40960:openfiles-cur=40960:
> >>
> >> but it is not really elegant solution.
> >>
> >>
> >> I this that at least order of suffix checking in /etc/rc must be changed
> >> from
> >> "for _suffix in {,-cur,-max}; do"
> >> to
> >> "for _suffix in {,-max,-cur}; do"
> >>
> >>
> >> Am I right? Or I missed something?
> >>
> >> --
> >> Best Wishes,
> >> Evgeny Grin
> >
> > First setting max and then cur should be enough.
> >
> > Moving this to tech@
> >
> > -Otto
> >
> > Index: rc
> > ===
> > RCS file: /cvs/src/etc/rc,v
> > retrieving revision 1.486
> > diff -u -p -r1.486 rc
> > --- rc 10 Jul 2016 09:08:18 - 1.486
> > +++ rc 29 Sep 2016 05:05:13 -
> > @@ -31,7 +31,7 @@ update_limit() {
> > local _cap=$2 _val # login.conf capability and its value
> > local _suffix
> >
> > - for _suffix in {,-cur,-max}; do
> > + for _suffix in {,-max,-cur}; do
> > _val=$(getcap -f /etc/login.conf -s ${_cap}${_suffix} daemon
> > 2>/dev/null)
> > [[ -n $_val ]] || continue
> > [[ $_val == infinity ]] && _val=unlimited
> >
>
> May be it also worth to mention in /etc/login.conf comments, that if
> both '-max' and '-cur' were set for "default" class, it's required to
> override explicitly both values in other classes, because 'openfiles'
> (without suffix) setting will be ineffective.
I don't think that is true in general. That only holds for daemon.
Other cases are handled by login.
-Otto
Re: login.conf processing by /etc/rc
On 29.09.2016 8:08, Otto Moerbeek wrote:
> On Thu, Sep 29, 2016 at 12:10:47AM +0300, Evgeny Grin wrote:
>
>> Hi!
>>
>> I configured freshly installed OpenBSD 6.0-release with
>>
>> kern.maxfiles=131072
>>
>> in /etc/sysctl.conf
>> and
>>
>> :openfiles-max=40960:openfiles-cur=40960:
>>
>> for daemon in /etc/login.conf
>>
>> And at each boot I see message:
>> kern.maxfiles: 7030 -> 131072
>> /etc/rc: ulimit: bad -n limit: Invalid argument
>>
>> I looked at /etc/rc and found that script at first step call 'ulimit -S
>> -n ' for value found for '-cur' and at second step call 'ulimit -H -n '
>> for value found for '-max'. That is incorrect as soft limit can't be set
>> to higher value than hard limit. Moreover, I can't just use
>> ":openfiles=40960:" for daemon class because "default" class has both
>> "-max" and "-cur" values - as result: at first step "40960" used for
>> both hard and soft limit, but immediately lowered by using "-cur" and
>> "-max" values from "default" class (getcap return them for "daemon"
>> class as well).
>>
>> As current workaround I use
>>
>> :openfiles=40960:openfiles-max=40960:openfiles-cur=40960:
>>
>> but it is not really elegant solution.
>>
>>
>> I this that at least order of suffix checking in /etc/rc must be changed
>> from
>> "for _suffix in {,-cur,-max}; do"
>> to
>> "for _suffix in {,-max,-cur}; do"
>>
>>
>> Am I right? Or I missed something?
>>
>> --
>> Best Wishes,
>> Evgeny Grin
>
> First setting max and then cur should be enough.
>
> Moving this to tech@
>
> -Otto
>
> Index: rc
> ===
> RCS file: /cvs/src/etc/rc,v
> retrieving revision 1.486
> diff -u -p -r1.486 rc
> --- rc10 Jul 2016 09:08:18 - 1.486
> +++ rc29 Sep 2016 05:05:13 -
> @@ -31,7 +31,7 @@ update_limit() {
> local _cap=$2 _val # login.conf capability and its value
> local _suffix
>
> - for _suffix in {,-cur,-max}; do
> + for _suffix in {,-max,-cur}; do
> _val=$(getcap -f /etc/login.conf -s ${_cap}${_suffix} daemon
> 2>/dev/null)
> [[ -n $_val ]] || continue
> [[ $_val == infinity ]] && _val=unlimited
>
May be it also worth to mention in /etc/login.conf comments, that if
both '-max' and '-cur' were set for "default" class, it's required to
override explicitly both values in other classes, because 'openfiles'
(without suffix) setting will be ineffective.
--
Best Wishes,
Evgeny Grin
Re: login.conf processing by /etc/rc
On Thu, Sep 29, 2016 at 12:10:47AM +0300, Evgeny Grin wrote:
> Hi!
>
> I configured freshly installed OpenBSD 6.0-release with
>
> kern.maxfiles=131072
>
> in /etc/sysctl.conf
> and
>
> :openfiles-max=40960:openfiles-cur=40960:
>
> for daemon in /etc/login.conf
>
> And at each boot I see message:
> kern.maxfiles: 7030 -> 131072
> /etc/rc: ulimit: bad -n limit: Invalid argument
>
> I looked at /etc/rc and found that script at first step call 'ulimit -S
> -n ' for value found for '-cur' and at second step call 'ulimit -H -n '
> for value found for '-max'. That is incorrect as soft limit can't be set
> to higher value than hard limit. Moreover, I can't just use
> ":openfiles=40960:" for daemon class because "default" class has both
> "-max" and "-cur" values - as result: at first step "40960" used for
> both hard and soft limit, but immediately lowered by using "-cur" and
> "-max" values from "default" class (getcap return them for "daemon"
> class as well).
>
> As current workaround I use
>
> :openfiles=40960:openfiles-max=40960:openfiles-cur=40960:
>
> but it is not really elegant solution.
>
>
> I this that at least order of suffix checking in /etc/rc must be changed
> from
> "for _suffix in {,-cur,-max}; do"
> to
> "for _suffix in {,-max,-cur}; do"
>
>
> Am I right? Or I missed something?
>
> --
> Best Wishes,
> Evgeny Grin
First setting max and then cur should be enough.
Moving this to tech@
-Otto
Index: rc
===
RCS file: /cvs/src/etc/rc,v
retrieving revision 1.486
diff -u -p -r1.486 rc
--- rc 10 Jul 2016 09:08:18 - 1.486
+++ rc 29 Sep 2016 05:05:13 -
@@ -31,7 +31,7 @@ update_limit() {
local _cap=$2 _val # login.conf capability and its value
local _suffix
- for _suffix in {,-cur,-max}; do
+ for _suffix in {,-max,-cur}; do
_val=$(getcap -f /etc/login.conf -s ${_cap}${_suffix} daemon
2>/dev/null)
[[ -n $_val ]] || continue
[[ $_val == infinity ]] && _val=unlimited
