[colug-432] ulimit

[Jon Miller]

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
>  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
>
>
>
> _______________________________________________
> colug-432 mailing list
> colug-432 at colug.net
> http://lists.colug.net/mailman/listinfo/colug-432
>