On Tue, Aug 5, 2014 at 6:49 AM, Ed Hynan <[email protected]> wrote:
> > On Mon, 4 Aug 2014, Philip Guenther wrote: > > On Sat, Aug 2, 2014 at 7:06 AM, Ed Hynan <[email protected]> wrote: >> > ... > That indicates that the requested -cur value was greater than the requested >> -max value, if any, or the current -max value if no change to the max was >> requested. >> > > Yes... -cur in the default class is 512, and ... > > # echo "ulimit -n" | su -m nobody > 256 > # echo "ulimit -nH" | su -m nobody > 384 > > I'm running the commands in a root shell. I set openfiles-cur=256 > and openfiles-max=384 for the daemon class, which is root's class > according to userinfo root. [*] > > So, after putting the original login.conf in place, and su - root > again on another pty, ulimit -nH is 768 (although the value 768 > does not appear in the original login.conf). Soft limit is 128. > > OK, it seems I've triggered the log message by reducing openfiles-max > in the daemon class, which is root's, but the interesting thing is > that the su command succeeds. Failure to set the resource limits isn't considered fatal for setusercontext(). It would be Bad if a typo there could leave you unable to login or su to root... ... > So, the absence openfiles-max in the original login.conf is > intentional? Before that log message, I was never prompted to > think this through this far. It wasn't necessary to set them, so why over-specify them? IIRC, we had actually increased the defaults not too long ago to handle the increased demands of stuff like gnome and firefox. If we wrote out all the limits, then upgrades would be more painful as more lines would have to change. Philip Guenther
