[colug-432] ulimit

[Jon Miller]

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