Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Bug in ulimit ?
- X-seq: zsh-workers 23288
- From: Stephane Chazelas <Stephane_Chazelas@xxxxxxxx>
- To: Micah Cowan <micah@xxxxxxxxxx>
- Subject: Re: Bug in ulimit ?
- Date: Tue, 17 Apr 2007 13:53:55 +0100
- Cc: zsh-workers@xxxxxxxxxx
- In-reply-to: <4624A79F.1020107@xxxxxxxxxx>
- Mail-followup-to: Micah Cowan <micah@xxxxxxxxxx>, zsh-workers@xxxxxxxxxx
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <46248CC2.4010901@xxxxxxxxxxxxx> <462493C0.20700@xxxxxxxxxx> <20070417094244.GA4955@xxxxxxxxxxxxxxx> <46249BC7.8070200@xxxxxxxxxx> <20070417104303.GB4955@xxxxxxxxxxxxxxx> <4624A79F.1020107@xxxxxxxxxx>
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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author