Date: Tue, 21 Jan 1997 02:10:34 +1100 (EST) From: David Nugent <davidn@unique.usn.blaze.net.au> To: FreeBSD-gnats-submit@freebsd.org Subject: kern/2535: filesize-cur resource limit reset to "infinity" Message-ID: <199701201510.CAA01575@labs.usn.blaze.net.au> Resent-Message-ID: <199701201520.HAA06270@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 2535
>Category: kern
>Synopsis: filesize-cur resource limit reset to "infinity"
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Mon Jan 20 07:20:01 PST 1997
>Last-Modified:
>Originator: David Nugent - davidn@blaze.net.au
>Organization:
Unique Computing, Melbourne, Australia
>Release: FreeBSD 3.0-CURRENT i386
>Environment:
Current (since login.conf support enabled).
>Description:
I'm hoping that this will be fixed by some future patches by
Bruce, but I'm logging it here just in case it isn't. :)
Enable resource settings via /etc/login.conf as usual.
Resources are all set by login(1) correctly, but after
the first program is run by the shell, the "filesize"
soft/current limit is reset to "infinite". This behaviour
is bizarre, to say the least.
>How-To-Repeat:
Set resource limits in /etc/login.conf, such as:
:cputime=infinity:\
:filesize=64M:\
:datasize=8M:\
:stacksize=8M:\
:coredumpsize=8M:\
:memoryuse=8M:\
:memorylocked=4M:\
:maxproc=20:\
:openfiles=20:\
:coredumpsize=infinity:\
Using tcsh in this example (same thing occurs with any
shell), insert the following into /etc/csh.login BEFORE
any external command is run, either directly or by backtick.
echo hard limits:
limit -h
echo soft limits:
limit
Insert the same AFTER the first external command is run.
Results:
BEFORE AFTER
hard limits:
cputime unlimited cputime unlimited
filesize 10240 kbytes filesize 10240 kbytes
datasize 8192 kbytes datasize 8192 kbytes
stacksize 8192 kbytes stacksize 8192 kbytes
coredumpsize 8192 kbytes coredumpsize 8192 kbytes
memoryuse 8192 kbytes memoryuse 8192 kbytes
memorylocked 4096 kbytes memorylocked 4096 kbytes
maxproc 20 maxproc 20
openfiles 20 openfiles 20
soft limits:
cputime unlimited cputime unlimited
| filesize 10240 kbytes filesize unlimited
datasize 8192 kbytes datasize 8192 kbytes
stacksize 8192 kbytes stacksize 8192 kbytes
coredumpsize 8192 kbytes coredumpsize 8192 kbytes
memoryuse 8192 kbytes memoryuse 8192 kbytes
memorylocked 4096 kbytes memorylocked 4096 kbytes
maxproc 20 maxproc 20
openfiles 20 openfiles 20
The vertical bar to the left highlights the mysterious change.
Aside: can soft limits be *validly* set higher than hard limits
like this? I wouldn't have thought so.
>Fix:
Remove the following line in sys/kern/kern_exit.c? I have no
idea why this line is even there in the first place. :-)
Can anyone explain why?
--- kern_exit.c.orig Wed Jan 15 14:55:26 1997
+++ kern_exit.c Tue Jan 21 01:51:26 1997
@@ -222,7 +222,7 @@
sp->s_leader = NULL;
}
fixjobc(p, p->p_pgrp, 0);
- p->p_rlimit[RLIMIT_FSIZE].rlim_cur = RLIM_INFINITY;
+ /* p->p_rlimit[RLIMIT_FSIZE].rlim_cur = RLIM_INFINITY; */
(void)acct_process(p);
#ifdef KTRACE
/*
My first guess is that it appears to be related to the process
accounting database so that the data file will not be
stopped from growing by virtue of the filesize resource limit
for the exiting process, which suggests that this fix is wrong,
and perhaps the real fix would require saving and restoring this
resource limit around the call to acct_process(). I'll leave
that up to someone knows this code better than I do.
Alternative (assuming the above paragraph/guess is correct):
--- kern_exit.c.orig Wed Jan 15 14:55:26 1997
+++ kern_exit.c Tue Jan 21 01:57:27 1997
@@ -120,6 +120,7 @@
register struct proc *q, *nq;
register struct vmspace *vm;
ele_p ep = exit_list;
+ rlim_t fsize_cur;
if (p->p_pid == 1) {
printf("init died (signal %d, exit %d)\n",
@@ -222,8 +223,10 @@
sp->s_leader = NULL;
}
fixjobc(p, p->p_pgrp, 0);
- p->p_rlimit[RLIMIT_FSIZE].rlim_cur = RLIM_INFINITY;
+ fsize_cur = p->p_rlimit[RLIMIT_FSIZE].rlim_cur;
+ p->p_rlimit[RLIMIT_FSIZE].rlim_cur = RLIM_INFINITY;
(void)acct_process(p);
+ p->p_rlimit[RLIMIT_FSIZE].rlim_cur = fsize_cur;
#ifdef KTRACE
/*
* release trace file
Should the hard limit be given similar treatment here?
It also occurs to me that the wrong p->p_rlimit[RLIMIT_FSIZE].rlim_cur
may be being used, which makes either fix incorrect, and the
desired effect of this line ineffective. This function appears
to be the kernel's exit process handler, so I have no idea why
the CALLING processes resources are being modified and not those
that apply to the the exiting process which I assume it should be...
Help! :-)
>Audit-Trail:
>Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701201510.CAA01575>