MOO-cows Mailing List Archive


DB crasher

[sent to moo-cows also because it may be of general interest]

   Date: 23 Apr 96 00:18:30 EDT
   From: Jefferson.M.Dubrule@Dartmouth.EDU (Jefferson M. Dubrule)

   On a MOO that I'm on, a "clock" runs in the background.  This monitors the
   number of tasks active on the MOO.  If it exceeds a certain number, all
   currently active tasks (except the clock) are killed and the owners of the
   tasks are sent mail about the fact that their tasks just got toasted.
   Unfortunately, the MOO is starting to have more players, and the clock is
   erroneously assuming a fork bomb is in progress.

I recommend upgrading to lambdamoo 1.7.9p2 and using the
queued_task_limit options that you can set on individual players and
on a moo-wide basis.  We've done that on LambdaMOO and are happy---one
fewer thing that can crash us.  If you go with the moo-wide setup
($server_options.queued_task_limit) you'll need to protect
add_property() and write a wrapper that disallows a player from
creating such a property on emself.  We did this on LambdaMOO to save
on the property overhead of 7000 instances of the property.  (If you
do byte quota, you'll also want to protect the addition of size_quota
on a player.)  If you have a lambdamoo character, @list #0:add_property
for details.

We set our $server_options.queued_task_limit to 100, with the idea
that we really were only interested in preventing forkbombs, and that
100 is really a huge number of forks that no legitimate (that is, not
out-of-control) process could want.  If your moo doesn't have a huge
amount of swap space available, you may want to lower this.  But in
any case, it's a much happier solution (for the users) than randomly
killing their tasks because some *other* player has created a monster.
And much easier on you, as the server does the enforcement.

      Judy Anderson yclept yduJ          'yduJ' rhymes with 'fudge' (personal mail) (work-related)
	Join the League for Programming Freedom,


Home | Subject Index | Thread Index