From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19511 invoked from network); 17 Apr 2007 13:34:42 -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.4 required=5.0 tests=AWL,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:34:42 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 19531 invoked from network); 17 Apr 2007 13:34:36 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 17 Apr 2007 13:34:36 -0000 Received: (qmail 28924 invoked by alias); 17 Apr 2007 13:34:31 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23291 Received: (qmail 28909 invoked from network); 17 Apr 2007 13:34:29 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 17 Apr 2007 13:34:29 -0000 Received: (qmail 19205 invoked from network); 17 Apr 2007 13:34:28 -0000 Received: from smtpout0171.sc1.he.tucows.com (HELO n066.sc1.he.tucows.com) (64.97.136.171) by a.mx.sunsite.dk with SMTP; 17 Apr 2007 13:34:25 -0000 Received: from sc.homeunix.net (82.26.163.82) by n066.sc1.he.tucows.com (7.2.069.1) id 45FC2B72001CB912; Tue, 17 Apr 2007 13:34:24 +0000 Received: from chazelas by sc.homeunix.net with local (Exim 4.63) (envelope-from ) id 1Hdnp2-0004Q5-8y; Tue, 17 Apr 2007 14:34:16 +0100 Date: Tue, 17 Apr 2007 14:34:16 +0100 From: Stephane Chazelas To: Micah Cowan , zsh-workers@sunsite.dk Subject: Re: Bug in ulimit ? Message-ID: <20070417133416.GF4955@sc.homeunix.net> Mail-Followup-To: Micah Cowan , zsh-workers@sunsite.dk 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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20070417132446.GE4955@sc.homeunix.net> User-Agent: Mutt/1.5.6i 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?