This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 461946 - modify per-process resource limit settings at runtime
modify per-process resource limit settings at runtime
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel (Show other bugs)
6.0
All Linux
high Severity high
: rc
: 6.0
Assigned To: Neil Horman
Mike Gahagan
http://lkml.org/lkml/2008/7/30/449
: FutureFeature
Depends On:
Blocks: 460951 522543 554559
  Show dependency treegraph
 
Reported: 2008-09-11 12:05 EDT by Helge Deller
Modified: 2013-12-05 09:47 EST (History)
10 users (show)

See Also:
Fixed In Version: kernel-2.6.32
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-02 15:14:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
initial rough pass at a patch to allow limit setting via proc (4.86 KB, patch)
2009-09-23 16:33 EDT, Neil Horman
no flags Details | Diff
cleaned up version of the patch (7.05 KB, patch)
2009-09-28 15:30 EDT, Neil Horman
no flags Details | Diff
backport of the upstream patchset (12.01 KB, patch)
2009-11-12 13:07 EST, Neil Horman
no flags Details | Diff

  None (edit)
Description Helge Deller 2008-09-11 12:05:22 EDT
We need some possibility to get rlimit settings on a per-process base from a system for monitoring and support purposes i.e. when investigating on remote customer systems. 

A patch to add a per-process /proc (or sysfs or anything else) interface for rlimit settings as discussed in http://thread.gmane.org/gmane.linux.kernel/272015 is something which would be useable. 

Ideally, it should also be possible to modify rlimit settings for distinct processes at run time. Such dynamic modification would help a lot to avoid impacting reboot of productive SAP servers just to change rlimit settings.
 
References
http://lwn.net/Articles/119703/
Comment 1 Bill Nottingham 2008-10-01 13:37:42 EDT
See also:
 http://lkml.org/lkml/2008/7/30/449
Comment 6 Bill Nottingham 2008-10-23 13:47:13 EDT
A backport of the limit display to RHEL 5 or RHEL 4 would need to be a separate request. As for the patch referenced in comment #1, while it was posted upstream, I don't think it's accepted, so it can't be pulled back yet.
Comment 7 Helge Deller 2008-10-24 10:03:57 EDT
Thanks Bill,
I've created bug 468381 (RHEL4) and bug 468380 (RHEL5) both requesting a backport of the current /proc/<pid>/limits behaviour.

So, this bug only leaves the feature request open to implement a feature to change some resource limit values of running processes on the fly (as the patch in your comment #1).
Comment 9 Neil Horman 2009-09-23 13:14:53 EDT
the /proc/<pid>/limits file was added to RHEL4 as part of bz 207340 in Feburary of 2008

it was added to RHEL5 as part of bz 253762 in December of 2007

Its been upstream since prior to Dec 2007 so its already in RHEL6, so we don't have to worry about a feature regression here on that part.

As for the ability to set resource limits by writing to that file, thats not upstream yet, nor does it exist in any RHEL.  It appears the referenced patch had several issues that the author didn't ever get back to us on.  Look like we should be able to finish te work, get it upstream and backport it however.
Comment 10 Neil Horman 2009-09-23 16:33:33 EDT
Created attachment 362352 [details]
initial rough pass at a patch to allow limit setting via proc

not tested yet, but this is something I think we can send upstream to get this working.
Comment 11 Neil Horman 2009-09-28 15:30:56 EDT
Created attachment 362936 [details]
cleaned up version of the patch

hers what I'll be sending upstream shortly
Comment 12 Neil Horman 2009-09-28 16:10:13 EDT
I've sent the patch upstream to akpm and linux-kernel if anyone would like to follow along
Comment 13 Neil Horman 2009-09-28 16:20:26 EDT
http://lkml.indiana.edu/hypermail/linux/kernel/0909.3/01431.html

Theres the thread.
Comment 20 Neil Horman 2009-11-12 13:07:44 EST
Created attachment 369278 [details]
backport of the upstream patchset

ok, heres the upstream backport from linux-next.  It allows you to do the following:

echo -n "A=B:C" > /proc/<pid>/limits

where 
A is the string of the limit as produced by catting the limits file, i.e. "Max core file size"

B is the current limit value or the string "unlimited"

C is the maximum hard limit value or the string "unlimited"

pid is the process id you wish to change.

This is a backport of the following commits:
5bcbae4eb046d179300495f728fe76bdf7678195
020d8f0554d6e5159009167532bb70f409c9f571
c07bb5092144a60f530edd53574e8826f37aa69e
ba9ba971a9241250646091935d77d2f31b7c15af
4a4a4e5f51d866284db401ea4d8ba5f0c91cc1eb
bab65b1e6c0fd797a1ecdb32911faa82947effd0
c1b9b7eaf7386a7f142d59a2bb433ac8217b0ad1

I've tested it successfully myself.
Comment 21 Helge Deller 2009-11-30 06:42:51 EST
Neil, thanks a lot for your work!!!
Helge
Comment 22 Neil Horman 2009-11-30 09:05:00 EST
no problem, glad to help :)
Comment 25 Mike Gahagan 2010-06-07 13:37:08 EDT
Confirmed this is present and functional in the 2.6.32-33 kernel.

[mpg@test1232 ~]$ cat /proc/$$/limits
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            10485760             unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             1024                 15740                processes 
Max open files            1024                 1024                 files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       15740                15740                signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us        

[mpg@test1232 ~]$ sudo echo -n "Max nice priority=5:5" > /proc/$$/limits
[mpg@test1232 ~]$ cat /proc/$$/limits
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            10485760             unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             1024                 15740                processes 
Max open files            1024                 1024                 files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       15740                15740                signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         5                    5                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us
Comment 26 James M. Leddy 2010-06-07 13:55:40 EDT
Hi Neil,

Quick question here: as I recall, upstream was more amenable to a syscall interface than they were to a rw file. It looks like we have this as a rw file, which is what I personally prefer. Is this what was decided upstream?
Comment 27 James M. Leddy 2010-06-07 13:56:21 EDT
Nevermind, should have read comment 20 first.
Comment 28 releng-rhel@redhat.com 2010-07-02 15:14:28 EDT
Red Hat Enterprise Linux Beta 2 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

Note You need to log in before you can comment on or make changes to this bug.