From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19649 invoked from network); 17 Apr 2007 13:25: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.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:25:12 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 234 invoked from network); 17 Apr 2007 13:25:07 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 17 Apr 2007 13:25:07 -0000 Received: (qmail 25107 invoked by alias); 17 Apr 2007 13:25:01 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23290 Received: (qmail 25090 invoked from network); 17 Apr 2007 13:24:59 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 17 Apr 2007 13:24:59 -0000 Received: (qmail 99182 invoked from network); 17 Apr 2007 13:24:59 -0000 Received: from smtpout0160.sc1.he.tucows.com (HELO n064.sc1.he.tucows.com) (64.97.136.160) by a.mx.sunsite.dk with SMTP; 17 Apr 2007 13:24:56 -0000 Received: from sc.homeunix.net (82.26.163.82) by n064.sc1.he.tucows.com (7.2.069.1) id 45FC2AFB0022F7BD; Tue, 17 Apr 2007 13:24:54 +0000 Received: from chazelas by sc.homeunix.net with local (Exim 4.63) (envelope-from ) id 1Hdnfq-0004OP-Rq; Tue, 17 Apr 2007 14:24:46 +0100 Date: Tue, 17 Apr 2007 14:24:46 +0100 From: Stephane Chazelas To: Micah Cowan , zsh-workers@sunsite.dk Subject: Re: Bug in ulimit ? Message-ID: <20070417132446.GE4955@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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20070417130316.GD4955@sc.homeunix.net> User-Agent: Mutt/1.5.6i 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. [...] 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? -- Stéphane