From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14845 invoked from network); 17 Apr 2007 15:03:04 -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 15:03:04 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 34048 invoked from network); 17 Apr 2007 15:02:58 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 17 Apr 2007 15:02:58 -0000 Received: (qmail 15735 invoked by alias); 17 Apr 2007 15:02:54 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23295 Received: (qmail 15721 invoked from network); 17 Apr 2007 15:02:52 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 17 Apr 2007 15:02:52 -0000 Received: (qmail 33541 invoked from network); 17 Apr 2007 15:02:52 -0000 Received: from smtpout0176.sc1.he.tucows.com (HELO n068.sc1.he.tucows.com) (64.97.136.176) by a.mx.sunsite.dk with SMTP; 17 Apr 2007 15:02:48 -0000 Received: from sc.homeunix.net (82.26.163.82) by n068.sc1.he.tucows.com (7.2.069.1) id 4622D78000011115; Tue, 17 Apr 2007 15:02:45 +0000 Received: from chazelas by sc.homeunix.net with local (Exim 4.63) (envelope-from ) id 1HdpCW-0004fp-8n; Tue, 17 Apr 2007 16:02:36 +0100 Date: Tue, 17 Apr 2007 16:02:36 +0100 From: Stephane Chazelas To: Micah Cowan , zsh-workers@sunsite.dk Subject: Re: [OT] Bug in ulimit ? Message-ID: <20070417150236.GG4955@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> <20070417133416.GF4955@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: <20070417133416.GF4955@sc.homeunix.net> User-Agent: Mutt/1.5.6i On Tue, Apr 17, 2007 at 02:34:16PM +0100, 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.... Not that rubbish though, the comment about it_prof_expires is valid I think. But what that means is that the processing of the process CPU timers is not scheduled. In: perl -W -MTime::HiRes -MBSD::Resource -le ' setrlimit(RLIMIT_CPU,0,RLIM_INFINITY); if (fork) {wait} else { Time::HiRes::setitimer(2, 0.5); while (1) { ; }}' The child process gets the SIGXCPU (not a SIGPROF) after half a second because the check_process_timers has been scheduled because of the itimer. So I beleive the statement about > But we use the zero value to mean "it was never set" is not accurate. the soft limit is initialised to infinity so there should be no reason AFAICT to treat 0 specially, so that this "1 second" cheating shouldn't be necessary (and I'd bet if there's a itimer due to fire sooner than 1 second from now, the SIGXCPU will be delivered earlier). So scheduling a check_process_timer for the next tick in sys_setitimer and for the first tick if rlim_cur is 0 in copy_signal should do it, I beleive. > > > 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