Zsh Mailing List Archive
Messages sorted by:
Re: ulimit -a: -r vs -N [was Re: pkgsrc patches for zsh]
- X-seq: zsh-workers 32792
- From: Thomas Klausner <tk@xxxxxxxxxx>
- To: Peter Stephenson <p.stephenson@xxxxxxxxxxx>
- Subject: Re: ulimit -a: -r vs -N [was Re: pkgsrc patches for zsh]
- Date: Tue, 24 Jun 2014 18:11:02 +0200
- Cc: zsh-workers@xxxxxxx
- In-reply-to: <firstname.lastname@example.org>
- List-help: <mailto:email@example.com>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <20120816142504.GO2428@danbala.tuwien.ac.at> <email@example.com> <20120817081109.GU2428@danbala.tuwien.ac.at> <firstname.lastname@example.org> <20120817105019.GB2428@danbala.tuwien.ac.at> <email@example.com> <20120817121605.GD2428@danbala.tuwien.ac.at> <20140624143711.GG13765@danbala.tuwien.ac.at> <sfid-H20140624firstname.lastname@example.org> <email@example.com>
On Tue, Jun 24, 2014 at 04:07:08PM +0100, Peter Stephenson wrote:
> On Tue, 24 Jun 2014 16:37:11 +0200
> Thomas Klausner <tk@xxxxxxxxxx> 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.
> 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 ");
> # endif /* HAVE_RLIMIT_RTPRIO */
> Those definitions come from a set of tests in configure.ac loooking like
> 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.
Messages sorted by: