On Tue, Apr 17, 2007 at 02:24:46PM +0100, Stephane Chazelas wrote:
On Tue, Apr 17, 2007 at 02:03:16PM +0100, Stephane Chazelas wrote:
[...]
So it would seem that the limit is inherited but not applied in
the child (and I couldn't see any signal being blocked or
ignored). So that's probably not a libc issue, rather a Linux
issue.
[...]
Please ignore this email, I was talking rubbish again, I should
probably get back to sleep....
The Linux code for setrlimit gives a hint:
if (it_prof_secs == 0 || new_rlim.rlim_cur <= it_prof_secs) {
unsigned long rlim_cur = new_rlim.rlim_cur;
cputime_t cputime;
if (rlim_cur == 0) {
/*
* The caller is asking for an immediate
RLIMIT_CPU
* expiry. But we use the zero value to
mean "it was
* never set". So let's cheat and make it
one second
* instead
*/
rlim_cur = 1;
}
It's stored as being "0" and armed with a 1 second delay. And on a
fork,
obviously, for the new process, there's no way to distinguish
between a 0 that means "not set" and a 0 that means exit
immediately.
And one can verify that it_prof_expires will be set to 0 in
copy_signal during the fork and that 0 means not armed in
check_process_timers.
But what's the point of setting a cputime of 0 anyway?