From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23579 invoked by alias); 24 Jun 2014 16:11:09 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 32792 Received: (qmail 23840 invoked from network); 24 Jun 2014 16:11:04 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.2 Date: Tue, 24 Jun 2014 18:11:02 +0200 From: Thomas Klausner To: Peter Stephenson Cc: zsh-workers@zsh.org Subject: Re: ulimit -a: -r vs -N [was Re: pkgsrc patches for zsh] Message-ID: <20140624161102.GJ13765@danbala.tuwien.ac.at> References: <20120816142504.GO2428@danbala.tuwien.ac.at> <20120816201848.4b442246@pws-pc.ntlworld.com> <20120817081109.GU2428@danbala.tuwien.ac.at> <20120817103803.73f82242@pwslap01u.europe.root.pri> <20120817105019.GB2428@danbala.tuwien.ac.at> <20120817123535.62ab00a1@pwslap01u.europe.root.pri> <20120817121605.GD2428@danbala.tuwien.ac.at> <20140624143711.GG13765@danbala.tuwien.ac.at> <20140624160708.6bef4d2c@pwslap01u.europe.root.pri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140624160708.6bef4d2c@pwslap01u.europe.root.pri> On Tue, Jun 24, 2014 at 04:07:08PM +0100, Peter Stephenson wrote: > On Tue, 24 Jun 2014 16:37:11 +0200 > Thomas Klausner wrote: > > A couple of days ago I noticed that 'ulimit -a' is now different (on > > NetBSD-6.99.44/x86_64 with zsh-5.0.5); see in the old mail below what > > it looked like before: > > > > -t: cpu time (seconds) unlimited > > -f: file size (blocks) unlimited > > -d: data seg size (kbytes) 262144 > > -s: stack size (kbytes) 4096 > > -c: core file size (blocks) unlimited > > -m: resident set size (kbytes) 32485916 > > -l: locked-in-memory size (kbytes) 10828638 > > -u: processes 160 > > -n: file descriptors 128 > > -b: socket buffer size (bytes) unlimited > > -v: virtual memory size (kbytes) unlimited > > -N 11: 160 > > > > It seems "-r" was replaced with "-N", and no help string is supplied. > > > > I've also tried zsh git head and see the same issue there. > > > > You probably know better where to look for this. > > That means it hasn't identified limit 11 as being associated with > what it thinks -r was previously associated with; because it's now > a generic limit it just blindly adds it without a help string. > > Sorry, I don't have access to NetBSD so not only don't I know what the > problem is I don't even know that it *is* a problem --- it's a problem > if someone thinks -N 11 is the same as -r, in which this needs > an appropriate test; or, if -N 11 is new, if that should be associated > with some other option. > > Someone who does know NetBSD will have to tell me what needs doing. So here's what ulimit -a looks like with NetBSD's /bin/sh: time (-t seconds ) unlimited file (-f blocks ) unlimited data (-d kbytes ) 262144 stack (-s kbytes ) 4096 coredump (-c blocks ) unlimited memory (-m kbytes ) 32485916 locked memory (-l kbytes ) 10828638 thread (-r threads ) 160 process (-p processes ) 160 nofiles (-n descriptors) 128 vmemory (-v kbytes ) unlimited sbsize (-b bytes ) unlimited If I raise the threads limit here to 161, the value for "-N 11" in zsh is also 161, so it's the same limit. Is that enough information? If not, please let me know what else you need. Thanks, Thomas > > In Src/rlimits.c, the only case for handling -r is currently marked as: > > # ifdef HAVE_RLIMIT_RTPRIO > case RLIMIT_RTPRIO: > if (head) > printf("-r: max rt priority "); > break; > # endif /* HAVE_RLIMIT_RTPRIO */ > > Those definitions come from a set of tests in configure.ac loooking like > > zsh_LIMIT_PRESENT(RLIMIT_RTPRIO) > > which are basically identical for all limits apart from the name --- > they basically look to see if a value for RLIMIT_RTPRIO is defined > in the headers. The headers are presumably correct as the other limits > are there. > > pws