[Prev][Next][Index][Thread]

# DB crasher

- Date: Tue, 23 Apr 1996 07:25:13 PDT
- From:
- cc: moo-cows.PARC@xerox.com
- In-Reply-to: "Jefferson M. Dubrule's message of 23 Apr 96 00:18:30 EDT <13714429@prancer.Dartmouth.EDU>"
- Posted-Date: Tue, 23 Apr 1996 07:25:13 -0700 (PDT)

    [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'
     yduJ@cs.stanford.edu (personal mail)   yduJ@harlequin.com (work-related)
    	Join the League for Programming Freedom, lpf@uunet.uu.net

References:

- Re: DB crasher

- From: Jefferson.M.Dubrule@dartmouth.edu (Jefferson M. Dubrule)

- Prev: Re: DB crasher
- Next: Re: DB crasher
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index