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