On Mon, 4 Aug 2014, Philip Guenther wrote:
On Sat, Aug 2, 2014 at 7:06 AM, Ed Hynan <eh_l...@optonline.net> wrote:
Saturday morning, saw this in /var/log/messages:
"Aug 2 08:29:12 lucy su: default: setting resource limit openfiles:
Invalid argument"
(BTW, I quoted a line I produced by hand: the time is wrong, should
have been approx. 03:30. The rest is the same.)
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.
That's from /etc/weekly, which uses 'su -m nobody' for locate db update
on line 52. The log message can be produced by hand with, e.g.:
# echo /bin/echo FOO | SHELL=/bin/sh nice -5 su -m nobody
invoked by root.
Hmm, I'm unable to reproduce that on my 5.6 system. Compare the output of
ulimit -nH and the openfiles-cur value in the login.conf. On my system,
the normal hard (i.e., -max) limit is 1024; is that not the case on yours?
If so, where is the smaller value coming from? The root .profile? Some
other system config file? Inherited from a lower limit on your personal
account when you su'ed to root?
See above. [*] why such limits, you may ask. Simply old and limited
hardware, in the role of home lan gateway router. I wanted to try
tighter limits, and use so far suggests they are not a problem for the
daemons in use. Last uptime before switch to 5.5: 408 days, but would
have been about 3 years if not for power failures outlasting the UPS.
So, I feel confident in those limits. Actually, those limits were in
place before 4.9, but I forget when. They seem OK.
BTW, I jumped from 4.9 to 5.5 so the 4.9 login.conf is the most
recent I have handy. The 4.9 login.conf likewise has only
openfiles-cur in default:, but I don't think I've seen that log
message before. Some verbosity recently added?
The setrlimit() syscall was changed to comply with POSIX and return an
error instead of (iirc) silently clamping the soft limit to the hard limit.
OK, I see the message is logged in lib/libc/gen/login_cap.c::gsetrl()
after setrlimit() fails (gsetrl() then returns -1).
Thanks for pointing that out; message is clear now. setusercontext(3)
does not fail at the gsetrl() failure; it proceeds anyway. That explains
why the log message is the only symptom and the /etc/weekly job
succeeds.
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.
-Ed
