Re: ulimit -a: -r vs -N [was Re: pkgsrc patches for zsh]

[Thomas Klausner <tk@xxxxxxxxxx>]

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.

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