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"><<a href="mailto:jonebird@gmail.com">jonebird@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
<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 <<a href="mailto:richardjhornsby@gmail.com">richardjhornsby@gmail.com</a>> wrote:<br>
><br>
> On Fri, Dec 2, 2011 at 2:57 PM, Mark Aufdencamp <<a href="mailto:mark@aufdencamp.com">mark@aufdencamp.com</a>> wrote:<br>
> > A helpful link:<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>
</div></div></blockquote></div><br></div>