Date: Tue, 08 Sep 2009 11:09:14 +0200 From: Ivan Radovanovic <rivanr@gmail.com> To: Jan Mikkelsen <janm-freebsd-hackers@transactionware.com> Cc: freebsd-hackers@FreeBSD.org Subject: Re: Kernel panic caused by fork Message-ID: <4AA61F3A.3040802@gmail.com> In-Reply-To: <E71733B7-16FB-435E-90BD-4869831CC61C@transactionware.com> References: <4AA4E7A7.60503@gmail.com> <E71733B7-16FB-435E-90BD-4869831CC61C@transactionware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jan Mikkelsen napisa:
> A quick observation: This is not "one process misbehaving", it is a
> large number of processes misbehaving. From an administrative point
> of view, I think the response is "call setrlimit(RLIMIT_NPROC, ...)",
> otherwise the expected behaviour is for your machine to stop making
> forward progress.
>
> Having said that, I agree that panics are bad and it would be nice if
> fork() returned EAGAIN, again and again and again. Or perhaps the
> machine should just panic ...
from fork(2) page - about errors
[EAGAIN] The system-imposed limit on the total number of pro-
cesses under execution would be exceeded. The limit
is given by the sysctl(3) MIB variable KERN_MAXPROC.
(The limit is actually ten less than this except for
the super user).
it seems that idea is to leave room for 10 more processes so root can
kill offending process, and limits at my system are (I am running pretty
much generic kernel)
kern.maxproc: 6164
kern.maxprocperuid: 5547
so if there are only two users running at the same time in the system
(the case when I did this testing) there is room for more than 500
processes after one user hits his limit - shouldn't panic I think
Regards,
Ivan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4AA61F3A.3040802>