From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11331 invoked from network); 17 Apr 2007 12:54:26 -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 12:54:26 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 61510 invoked from network); 17 Apr 2007 12:54:19 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 17 Apr 2007 12:54:19 -0000 Received: (qmail 20492 invoked by alias); 17 Apr 2007 12:54:14 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23288 Received: (qmail 20482 invoked from network); 17 Apr 2007 12:54:12 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 17 Apr 2007 12:54:12 -0000 Received: (qmail 61108 invoked from network); 17 Apr 2007 12:54:12 -0000 Received: from smtpout0190.sc1.he.tucows.com (HELO n066.sc1.he.tucows.com) (64.97.136.190) by a.mx.sunsite.dk with SMTP; 17 Apr 2007 12:54:05 -0000 Received: from sc.homeunix.net (82.26.163.82) by n066.sc1.he.tucows.com (7.2.069.1) id 45FC2B72001CAC13; Tue, 17 Apr 2007 12:54:02 +0000 Received: from chazelas by sc.homeunix.net with local (Exim 4.63) (envelope-from ) id 1HdnBz-0004JB-50; Tue, 17 Apr 2007 13:53:55 +0100 Date: Tue, 17 Apr 2007 13:53:55 +0100 From: Stephane Chazelas To: Micah Cowan Cc: zsh-workers@sunsite.dk Subject: Re: Bug in ulimit ? Message-ID: <20070417125355.GC4955@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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4624A79F.1020107@cowan.name> User-Agent: Mutt/1.5.6i On Tue, Apr 17, 2007 at 03:55:27AM -0700, Micah Cowan wrote: [...] > > ulimit -t > > > > doesn't set the limit to 0 but to infinity (in effect, to the > > hard limit). > > > > It's ulimit -t 0 > > to set the limit to 0 (well actually, 1 second in that case). > > > Originally responded to this directly, but then realized that the > veracity of this statement is pertinent to the next message I sent as > well, so it's worth addressing on-list, in case it isn't clear to others. > > ulimit -t > > doesn't set the limit _at_all_; it prints it (hence the "0", above). [...] Indeed sorry. I can now see the same behavior as you did, and it doesn't seem to be linked to zsh indeed. The limit doesn't seem to get inherited by the child process: ~$ perl -MBSD::Resource -le 'setrlimit(RLIMIT_CPU,0,RLIM_INFINITY); print for getrlimit(RLIMIT_CPU); while (1) { ; }' 0 -1 zsh: cpu limit exceeded perl -MBSD::Resource -le (152)~$ perl -MBSD::Resource -le 'setrlimit(RLIMIT_CPU,0,RLIM_INFINITY); print for getrlimit(RLIMIT_CPU); if (fork) {wait} else {while (1) { ; }}' 0 -1 Which contradicts this note in setrlimit(2): NOTES A child process created via fork(2) inherits its parents resource limits. Resource limits are preserved across execve(2). Though strictly speaking, stracing perl, there's no fork() system call but a clone(). There is a call to libc's fork() function (verified using ltrace), so it may be a libc issue. Maybe the limits should be dupplicated in user space by glibc's fork()? $ getconf GNU_LIBC_VERSION glibc 2.3.6 -- Stéphane