good point. it seems that on open (yet restricted) systems, users wouldn't be ./configure'ing much software, particularly if quotas are small and network access is next to none, which would leave me inclined to go with the kill().
But, of course, that would just be for my own uses. Perhaps there's a way to do both? Either have two login.conf variables, one for delay and one for timespan, or even combine them into one with a 'd' or 't' suffix? I guess the kill() isn't particularly necessary. -Anthony. On Mon, Feb 04, 2002 at 05:35:51PM -0600, Dan Nelson wrote: > In the last episode (Feb 04), Anthony Schneider said: > > I've actually wanted something like this for a while and have considered > > coding it myself. Perhaps this could go into a login.conf variable > > (which I would have to create myself), but originally my plan was basically > > kill off parent processes with the uid of the user who is fork()'ing too > > often (200 per 10 seconds sounds good) simply hard-coded. > > 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]
msg31411/pgp00000.pgp
Description: PGP signature
