From: Stephane Chazelas <Stephane_Chazelas@yahoo.fr>
To: Micah Cowan <micah@cowan.name>
Cc: zsh-workers@sunsite.dk
Subject: Re: Bug in ulimit ?
Date: Tue, 17 Apr 2007 13:53:55 +0100 [thread overview]
Message-ID: <20070417125355.GC4955@sc.homeunix.net> (raw)
In-Reply-To: <4624A79F.1020107@cowan.name>
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
<Ctrl-C>
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
next prev parent reply other threads:[~2007-04-17 12:54 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-17 9:00 David Peer
2007-04-17 9:30 ` Micah Cowan
2007-04-17 9:33 ` David Peer
2007-04-17 9:42 ` Stephane Chazelas
2007-04-17 10:04 ` Micah Cowan
2007-04-17 10:43 ` Stephane Chazelas
2007-04-17 10:55 ` Micah Cowan
2007-04-17 12:53 ` Stephane Chazelas [this message]
2007-04-17 13:03 ` Stephane Chazelas
2007-04-17 13:24 ` Stephane Chazelas
2007-04-17 13:34 ` Stephane Chazelas
2007-04-17 13:54 ` David Peer
2007-04-17 13:57 ` David Peer
2007-04-17 15:02 ` [OT] " Stephane Chazelas
2007-04-17 10:49 ` Micah Cowan
2007-04-17 14:15 ` Tom Alsberg
2007-04-17 15:48 ` David Peer
[not found] ` <20070417151501.GH4955@sc.homeunix.net>
2007-04-18 7:46 ` (Off-Topic) " Tom Alsberg
2007-04-18 8:22 ` Stephane Chazelas
2007-04-18 9:23 ` (Off-Topic) Bug in ulimit? Tom Alsberg
2007-04-18 10:10 ` Stephane Chazelas
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=20070417125355.GC4955@sc.homeunix.net \
--to=stephane_chazelas@yahoo.fr \
--cc=micah@cowan.name \
--cc=zsh-workers@sunsite.dk \
/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).