From: Thomas Klausner <tk@giga.or.at>
To: Peter Stephenson <p.stephenson@samsung.com>
Cc: zsh-workers@zsh.org
Subject: Re: ulimit -a: -r vs -N [was Re: pkgsrc patches for zsh]
Date: Tue, 24 Jun 2014 18:11:02 +0200 [thread overview]
Message-ID: <20140624161102.GJ13765@danbala.tuwien.ac.at> (raw)
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 <tk@giga.or.at> 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
next prev parent reply other threads:[~2014-06-24 16:11 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-16 12:04 tgoto issue in zsh-5.0.0 Thomas Klausner
2012-08-16 13:07 ` Peter Stephenson
2012-08-16 13:20 ` Thomas Klausner
2012-08-16 13:25 ` Peter Stephenson
2012-08-16 14:25 ` pkgsrc patches for zsh [was Re: tgoto issue in zsh-5.0.0] Thomas Klausner
2012-08-16 19:18 ` Peter Stephenson
2012-08-17 8:11 ` Thomas Klausner
2012-08-17 9:38 ` Peter Stephenson
2012-08-17 10:50 ` Thomas Klausner
2012-08-17 11:35 ` Peter Stephenson
2012-08-17 12:16 ` Thomas Klausner
2012-08-17 13:27 ` Peter Stephenson
2014-06-24 14:37 ` ulimit -a: -r vs -N [was Re: pkgsrc patches for zsh] Thomas Klausner
2014-06-24 15:07 ` Peter Stephenson
2014-06-24 16:11 ` Thomas Klausner [this message]
2014-06-24 16:26 ` Peter Stephenson
2014-06-24 17:09 ` Thomas Klausner
2014-06-25 8:26 ` Peter Stephenson
2014-06-25 8:36 ` Thomas Klausner
2014-06-25 10:33 ` Peter Stephenson
2014-06-25 11:00 ` Thomas Klausner
2014-06-25 11:11 ` Peter Stephenson
2014-06-25 12:18 ` Thomas Klausner
2014-06-26 8:31 ` Daniel Shahaf
2014-06-26 9:49 ` Peter Stephenson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140624161102.GJ13765@danbala.tuwien.ac.at \
--to=tk@giga.or.at \
--cc=p.stephenson@samsung.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).