richardjhornsby at gmail.com
Sat Jan 14 16:30:46 EST 2012
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?
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
>> sponding resource. The hard limit acts as a ceiling for the
>> limit: an unprivileged process may only set its soft limit to a
>> in the range from 0 up to the hard limit, and (irreversibly) lower
>> hard limit. A privileged process (under Linux: one with
>> CAP_SYS_RESOURCE capability) may make arbitrary changes to either
>> 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:
>>> -- Jon Miller
>>> On Mon, Dec 19, 2011 at 3:26 PM, Rick Hornsby <richardjhornsby at gmail.com>
>>>> On Fri, Dec 2, 2011 at 2:57 PM, Mark Aufdencamp <mark at aufdencamp.com>
>>>>> A helpful link:
>>>> 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.
>>>> colug-432 mailing list
>>>> colug-432 at colug.net
>>> colug-432 mailing list
>>> colug-432 at colug.net
>> colug-432 mailing list
>> colug-432 at colug.net
> colug-432 mailing list
> colug-432 at colug.net
More information about the colug-432