[colug-432] ulimit

[Rick Hornsby]

Unfortunately, this has come up again.  I thought we were right setting the ulimit in /etc/security/limits.conf, but when I looked at the actual tomcat process which was started from an init script which contains this line:

su - tomcat $TOMCAT_INSTANCE/bin/startup.sh

The FD limit is maybe getting inherited from the shell which started it - root's.  The value for root is the system default of 1024, but 8192 for the tomcat user in /etc/security/limits.conf.

I also tested this by kicking off tail using sudo (su terminated with a '&' acts the same)

sudo -bu tomcat tail -f /var/log/dmesg > /dev/null

When I check the limit in /proc/PID/limits, it is 1024 not 8192.  If instead of doing sudo right away, I do 

ulimit -n someval; sudo -bu tomcat …

then the tail process, owned by tomcat, gets a limit of someval.

I really don't want to do a hack and have the init script read /etc/security/limits.conf for the tomcat user, change the value and start tomcat …


any other thoughts?

thanks
-rick

On Dec 19, 2011, at 17:38 , Jon Miller wrote:

> Yes Jeff, you are correct and have the best answer to the question. My
> answer was the "cowboy" answer which really isn't expected to be
> followed but merely interesting to mention what you can accomplish via
> a kernel module hack. And as you've pointed out, you can update your
> ulimit value, within your hard limit, from within the process itself.
> In my scenario, I needed to alter a process I did not own and
> furthermore update a value potentiall beyond it's hard limit. Again,
> that was my cowboy solution.
> 
> -- Jon Miller
> 
> On Mon, Dec 19, 2011 at 4:17 PM, Jeff Frontz <jeff.frontz at gmail.com> wrote:
>> Slight correction - you can change ulimit values on a running process on a
>> stock 2.6 kernel, but only from inside the process (via a call to setrlimit)
>> and only to decrease it in an unprivileged process.
>> 
>>> From the FC7 setrlimit(2) man page:
>> 
>>        The soft limit is the value that the kernel  enforces  for  the
>>  corre-
>>        sponding  resource.   The  hard  limit  acts  as a ceiling for the
>> soft
>>        limit: an unprivileged process may only set its soft limit to  a
>>  value
>>        in  the range from 0 up to the hard limit, and (irreversibly) lower
>> its
>>        hard  limit.   A  privileged  process  (under  Linux:  one   with
>> the
>>        CAP_SYS_RESOURCE capability) may make arbitrary changes to either
>> limit
>>        value.
>> 
>> Jeff
>> 
>> 
>> On Mon, Dec 19, 2011 at 4:05 PM, Jon Miller <jonebird at gmail.com> wrote:
>>> 
>>> Correct, you're not supposed to be able to change a ulimit value of a
>>> currently running process. That said, I've done it before via a custom
>>> kernel module. I was actually originally interested in resetting a
>>> signal handler for a currently running process in order to
>>> successfully generate a corefile. In the process of testing, we found
>>> out that the corefile I was getting was zero bytes because their
>>> ulimit for corefile size was set to 0. So, I made another update to
>>> the kernel module and was able to change the corefile size ulimit
>>> value to unlimited on the fly too.
>>> 
>>> All the while we had a case open with Novell & IBM and needless to
>>> say, they didn't like the idea of me creating a kernel module but it
>>> worked and we got the desired corefile finally. I have a short writeup
>>> on the ordeal on my blog:
>>> 
>>> http://jonebird.com/2007/06/21/stripping-another-process-of-its-signal-handler/
>>> 
>>> -- Jon Miller
>>> 
>>> On Mon, Dec 19, 2011 at 3:26 PM, Rick Hornsby <richardjhornsby at gmail.com>
>>> wrote:
>>>> 
>>>> On Fri, Dec 2, 2011 at 2:57 PM, Mark Aufdencamp <mark at aufdencamp.com>
>>>> wrote:
>>>>> A helpful link:
>>>>> 
>>>>> 
>>>>> http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/
>>>> 
>>>> Thanks.  That was one of the things I read before posting that got me
>>>> really turned around.  The language is very confusing, especially when
>>>> he says things like "75000 files normal user can have open in single
>>>> login session."  That makes it seem like it is almost a per-user
>>>> (per-session more specifically) limit.
>>>> 
>>>> Someone else said that the ulimit was a per-process restriction, and
>>>> this appears to be true. /proc/<pid>/limits confirms this.
>>>> 
>>>> Recompiling the kernel isn't an option, but it is good to know that
>>>> this is where the default of 1024 comes from.  Based on what folks
>>>> suggested here and additional research, /etc/security/limits.conf is
>>>> the place to set it.  Something that took me a while to get is the
>>>> soft/hard limits.  Unlike disk/printer quotas, these different limits
>>>> do not refer to warnings or other information that lets the user know
>>>> they're about to run out.  Rather, the hard limit is the
>>>> kernel-enforced maximum.  The soft limit can be set by the user, up to
>>>> the hard limit.  So maybe the hard limit is 1024, but they decide a
>>>> process has run away if it hits 128 open FDs.  That would be a use for
>>>> the soft limit.  I believe, like a pid's nice value, the user can
>>>> lower their own hard limit (priority), but once lowered, they cannot
>>>> raise it.
>>>> 
>>>> It does not, however, appear that it is possible to change the ulimit
>>>> of a currently running process.  When a process starts up, the
>>>> kernel(?) figures out what limits it should have, and those last for
>>>> the life of the pid.
>>>> 
>>>> ulimit is just one of those things that seems to be poorly documented
>>>> and not well understood.
>>>> 
>>>> -rick
>>>> _______________________________________________
>>>> colug-432 mailing list
>>>> colug-432 at colug.net
>>>> http://lists.colug.net/mailman/listinfo/colug-432
>>> 
>>> _______________________________________________
>>> colug-432 mailing list
>>> colug-432 at colug.net
>>> http://lists.colug.net/mailman/listinfo/colug-432
>> 
>> 
>> 
>> _______________________________________________
>> colug-432 mailing list
>> colug-432 at colug.net
>> http://lists.colug.net/mailman/listinfo/colug-432
>> 
> 
> _______________________________________________
> colug-432 mailing list
> colug-432 at colug.net
> http://lists.colug.net/mailman/listinfo/colug-432