[colug-432] ulimit

[Jeff Frontz]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.colug.net/pipermail/colug-432/attachments/20111219/4d205f68/attachment.html