From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16954 invoked from network); 17 Apr 2007 13:55:12 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.8 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 17 Apr 2007 13:55:12 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 43801 invoked from network); 17 Apr 2007 13:55:07 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 17 Apr 2007 13:55:07 -0000 Received: (qmail 3570 invoked by alias); 17 Apr 2007 13:55:02 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23292 Received: (qmail 3545 invoked from network); 17 Apr 2007 13:55:00 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 17 Apr 2007 13:55:00 -0000 Received: (qmail 43246 invoked from network); 17 Apr 2007 13:55:00 -0000 Received: from cs1.cs.huji.ac.il (132.65.16.10) by a.mx.sunsite.dk with SMTP; 17 Apr 2007 13:54:57 -0000 Received: from wrath.cs.huji.ac.il ([132.65.80.62]) by cs1.cs.huji.ac.il with esmtp id 1Hdo8w-0008lV-CI; Tue, 17 Apr 2007 16:54:50 +0300 Message-ID: <4624D1AA.4030902@cs.huji.ac.il> Date: Tue, 17 Apr 2007 16:54:50 +0300 From: David Peer Reply-To: davidpeer@cs.huji.ac.il Organization: Hebrew University - Computer User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Micah Cowan , zsh-workers@sunsite.dk Subject: Re: Bug in ulimit ? References: <46248CC2.4010901@cs.huji.ac.il> <462493C0.20700@cowan.name> <20070417094244.GA4955@sc.homeunix.net> <46249BC7.8070200@cowan.name> <20070417104303.GB4955@sc.homeunix.net> <4624A79F.1020107@cowan.name> <20070417125355.GC4955@sc.homeunix.net> <20070417130316.GD4955@sc.homeunix.net> <20070417132446.GE4955@sc.homeunix.net> <20070417133416.GF4955@sc.homeunix.net> In-Reply-To: <20070417133416.GF4955@sc.homeunix.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit 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