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.<div><br></div><div>
>From the FC7 setrlimit(2) man page:</div><div><br></div><div><div>       The soft limit is the value that the kernel  enforces  for  the  corre-</div><div>       sponding  resource.   The  hard  limit  acts  as a ceiling for the soft</div>
<div>       limit: an unprivileged process may only set its soft limit to  a  value</div><div>       in  the range from 0 up to the hard limit, and (irreversibly) lower its</div><div>       hard  limit.   A  privileged  process  (under  Linux:  one   with   the</div>
<div>       CAP_SYS_RESOURCE capability) may make arbitrary changes to either limit</div><div>       value.</div><div><br></div><div>Jeff</div><div><br></div><div><br></div><div class="gmail_quote">On Mon, Dec 19, 2011 at 4:05 PM, Jon Miller <span dir="ltr">&lt;<a href="mailto:jonebird@gmail.com">jonebird@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Correct, you&#39;re not supposed to be able to change a ulimit value of a<br>
currently running process. That said, I&#39;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 &amp; IBM and needless to<br>
say, they didn&#39;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>
<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>
<font color="#888888"><br>
-- Jon Miller<br>
</font><div><div></div><div class="h5"><br>
On Mon, Dec 19, 2011 at 3:26 PM, Rick Hornsby &lt;<a href="mailto:richardjhornsby@gmail.com">richardjhornsby@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Fri, Dec 2, 2011 at 2:57 PM, Mark Aufdencamp &lt;<a href="mailto:mark@aufdencamp.com">mark@aufdencamp.com</a>&gt; wrote:<br>
&gt; &gt; A helpful link:<br>
&gt; &gt;<br>
&gt; &gt; <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>
&gt;<br>
&gt; Thanks.  That was one of the things I read before posting that got me<br>
&gt; really turned around.  The language is very confusing, especially when<br>
&gt; he says things like &quot;75000 files normal user can have open in single<br>
&gt; login session.&quot;  That makes it seem like it is almost a per-user<br>
&gt; (per-session more specifically) limit.<br>
&gt;<br>
&gt; Someone else said that the ulimit was a per-process restriction, and<br>
&gt; this appears to be true. /proc/&lt;pid&gt;/limits confirms this.<br>
&gt;<br>
&gt; Recompiling the kernel isn&#39;t an option, but it is good to know that<br>
&gt; this is where the default of 1024 comes from.  Based on what folks<br>
&gt; suggested here and additional research, /etc/security/limits.conf is<br>
&gt; the place to set it.  Something that took me a while to get is the<br>
&gt; soft/hard limits.  Unlike disk/printer quotas, these different limits<br>
&gt; do not refer to warnings or other information that lets the user know<br>
&gt; they&#39;re about to run out.  Rather, the hard limit is the<br>
&gt; kernel-enforced maximum.  The soft limit can be set by the user, up to<br>
&gt; the hard limit.  So maybe the hard limit is 1024, but they decide a<br>
&gt; process has run away if it hits 128 open FDs.  That would be a use for<br>
&gt; the soft limit.  I believe, like a pid&#39;s nice value, the user can<br>
&gt; lower their own hard limit (priority), but once lowered, they cannot<br>
&gt; raise it.<br>
&gt;<br>
&gt; It does not, however, appear that it is possible to change the ulimit<br>
&gt; of a currently running process.  When a process starts up, the<br>
&gt; kernel(?) figures out what limits it should have, and those last for<br>
&gt; the life of the pid.<br>
&gt;<br>
&gt; ulimit is just one of those things that seems to be poorly documented<br>
&gt; and not well understood.<br>
&gt;<br>
&gt; -rick<br>
&gt; _______________________________________________<br>
&gt; colug-432 mailing list<br>
&gt; <a href="mailto:colug-432@colug.net">colug-432@colug.net</a><br>
&gt; <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>
</div></div></blockquote></div><br></div>