First of all, thanks to all for telling their opinions :)
I prefer to enforce both some preventive software measures as well
administrative ones. But i do not what that some
kiddie/newbie/clueless one to take down box that is shared among
many other students as well.
After listening to your all opinions I'm sure that this is to be
implemented. i'll go on.
-skip-
-> Killing off parent procs could really upset a regular user who is
-> running ./configure, which could easily spawn a couple undred processes
-> in 10 seconds. Maybe simply delay the fork() until the rate drops?
->
-> --
-> Dan Nelson
-> [EMAIL PROTECTED]
First of all I suggest not to kill parent, but childs. They must die
with EAGAIN error, as manual page fork(2) describes. If we will
delay forks we will exhaust all kernel memory promptly.
Second - i specially told about 2 limits - how many processes to
spawn and in what time range - i.e. you can allow '1000 process for
60 secs' and it'll allow ./conifgure to run.
[IMPLEMENTATION QUESTIONS]
Can i suggest that rlim_t is at least 32 bit long ?
I want to pack process limit and period length in one double word.
(for example 16 bits for process count limit and 16 - for time,
is gives range from 1 fork in 18 hours:) to 2^16 forks in 1 second)
Or i should create 2 different RLIMIT_ constants ?
thanx in advance
--
Gaspar Chilingarov
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
