[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ulimit bug

From: Chet Ramey
Subject: Re: ulimit bug
Date: Sat, 05 Mar 2011 16:41:33 -0500
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7

On 3/5/11 2:36 PM, Dmitry V. Levin wrote:
> Hi,
> On Sat, Mar 05, 2011 at 03:36:39PM +0300, Sergey Zhumatiy wrote:
>>   Hello!
>>   I just had discover (on my back) ulimit command bug.
>>   There is "resident set" limit, which is set in PAGES. But ulimit 
>> command shows it as kBytes. On by system page size size is 4Kb, so 
>> difference is four times...
>>   Simple test (using raw getrlimit call) shows, that ulimit sets and 
>> shown PAGES, but not kBytes. Please, fix it!
> Looks like you've got it all wrong.
> ulimit -m operates in units of 1024 pages each:
> $ strace -e setrlimit bash -c 'ulimit -m 1'
> setrlimit(RLIMIT_RSS, {rlim_cur=1024, rlim_max=1024}) = 0
> $ strace -e setrlimit bash -c 'ulimit -m 1234'
> setrlimit(RLIMIT_RSS, {rlim_cur=1234*1024, rlim_max=1234*1024}) = 0

The original poster is more-or-less correct.  The ulimit -m option takes
an argument that is in 1024-byte units.  It assumes that the RLIMIT_RSS
resource limit is specified to setrlimit in terms of bytes, as it has
been since it was first defined in 4.2 BSD, and as it is on every other
system that implements it.  I'm not sure why Linux decided to interpret
the argument as a number of pages.  Another annoying system difference
to code around.


``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]