Re: Bug in ulimit ?

[David Peer <davidpeer@cs.huji.ac.il>]

I hope kernel people will add it to the next kernel release,

but here is one rapid fix that solves the problem.

(you will not see the new limit of 1 sec but you'll still see it set to 
0, but its 1 sec - believe me && try,

 if you want to see it, fork another any shell and you'll see it....bug 
or feature?!)


Before the line: *old_rlim = new_rlim;


add:


if (resource == RLIMIT_CPU && new_rlim.rlim_cur == 0) {
            /*
             * The caller is asking for an immediate RLIMIT_CPU
             * expiry.  But we use the zero value to mean "it was
             * never set".  So let's cheat and make it one second
             * instead
             */
            new_rlim.rlim_cur = 1;
        }


You can remove the dumb if statement that does nothing cause the 
assignment occurs(*old_rlim = new_rlim) before

so it has no meaning! : if (rlim_cur == 0) {....}


David



Stephane Chazelas wrote:

> On Tue, Apr 17, 2007 at 02:24:46PM +0100, Stephane Chazelas wrote:
>   
>> On Tue, Apr 17, 2007 at 02:03:16PM +0100, Stephane Chazelas wrote:
>> [...]
>>     
>>> So it would seem that the limit is inherited but not applied in
>>> the child (and I couldn't see any signal being blocked or
>>> ignored). So that's probably not a libc issue, rather a Linux
>>> issue.
>>>       
>> [...]
>>     
>
> Please ignore this email, I was talking rubbish again, I should
> probably get back to sleep....
>
>   
>> The Linux code for setrlimit gives a hint:
>>
>>         if (it_prof_secs == 0 || new_rlim.rlim_cur <= it_prof_secs) {
>>                 unsigned long rlim_cur = new_rlim.rlim_cur;
>>                 cputime_t cputime;
>>
>>                 if (rlim_cur == 0) {
>>                         /*
>>                          * The caller is asking for an immediate RLIMIT_CPU
>>                          * expiry.  But we use the zero value to mean "it was
>>                          * never set".  So let's cheat and make it one second
>>                          * instead
>>                          */
>>                         rlim_cur = 1;
>>                 }
>>
>> It's stored as being "0" and armed with a 1 second delay. And on a fork,
>> obviously, for the new process, there's no way to distinguish
>> between a 0 that means "not set" and a 0 that means exit
>> immediately.
>>
>> And one can verify that it_prof_expires will be set to 0 in
>> copy_signal during the fork and that 0 means not armed in
>> check_process_timers.
>>
>> But what's the point of setting a cputime of 0 anyway?
>>     
>
>   


-- 
David Peer <!> davidpeer@cs.huji.ac.il
CS System Group | Phone: 02 - 6586942
School of Computer Science and Engineering
Hebrew University of Jerusalem - Israel
Edmund Safra Campus - Givat Ram