# DB crasher (fwd)

Rich Connamacher (phantom@baymoo.sfsu.edu)
Tue, 23 Apr 1996 16:04:03 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    ---------- Forwarded message ----------
    Date: Tue, 23 Apr 1996 09:52:36 -0700 (PDT)
    From: Judy Anderson <yduj@CS.Stanford.EDU>
    To: phantom@baymoo.sfsu.edu
    Subject: DB crasher

       Date: Mon, 22 Apr 1996 23:36:18 -0700 (PDT)
       From: Rich Connamacher <phantom@baymoo.sfsu.edu>

       (Note that, if there really were a true fork bomb attack on that moo,
       unless the clock cycles so frequently as to lag the entire moo, the fork
       bomb could grow so fast that the clock will choke and die trying to
       keep up..  If they don't believe me, tell them to give me a prog bit on
       their moo and an okay to go ahead and crash it.  Whoever wrote it
       must not understand exponential mathematics.)

    Fortunately the scheduler sufficiently discriminates against players
    who use huge amounts of CPU time, that, as long as you have enough
    swap space to hold the initial round of tasks (probably 60,000 can get
    spawned before the scheduler's discriminatory action takes over enough
    to give relief), you do have plenty of time to deal with it.

    Advice to wizards combatting forkbombs:  (1) make yourself two or
    three other wizard characters.  Your wizard will be subject to the
    scheduler's bias as well.  (2) make sure you have the LambdaMOO
    @killquiet version of @kill -- by not printing out the tasks as they
    are killed, you can get many hundreds more in each @kill command.  (3)
    Be aware of the bug in the scheduler that gives you relief from its
    bias if you disconnect and reconnect.

    So, you use your three wizard connections to figure out which
    character has the bazillion forks. If queued_tasks() doesn't give you
    out of seconds you're in good shape.  If it does, set
    $server_options.foreground_seconds to 100.  (Remember to change it
    back when you're done :-)  Then you can use @forked, which will
    presumably have the culprit's forks pretty early in the list, as
    they're the most lagged.  Now @killquiet all Culprit.  Thousands of
    tasks will die.  You may have to use more than one @killq.  Don't let
    it suspend; it's hosed at that point and requires a different wizard
    (or a fresh disconnected/reconnected wizard) to try it again.  Of
    course, with your other wizard connections you are @deprogrammering
    and @rmverbing.

    Before I figured out the disconnect/reconnect scheduler bug (btw, it's
    the reconnect that does it, not the disconnect, I've experimented), I
    used to coordinate efforts with lots of wizards.  "Page ho_yan please
    type ..." "page heathcliff Please type..." plus of course giving all
    my other characters wizbits.  If one of your wizard connections gets
    lagged, don't wait for it, use a different one.  I've been lagged for
    anup to two hours after executing a 10 second queued_tasks() that
    returned 100,000 tasks.  Remember, even though the culprit is subject
    to the same scheduler discrimination that you are, he still does get
    to run sometimes, and spawn 5000 more tasks each try.  So you are in a
    hurry to get it fixed.

    If your moo version is so old you don't have
    $server_options.foreground_seconds as an option, the following code
    will assist.

    for x in (players())
      if (x.programmer && !x.wizard)
        fork (0)
          set_task_perms(x);
          player:tell("about to do ", x, " ", x.name);
          player:tell(length(queued_tasks()), " for ", x.name, " ", x);
        endfork
        suspend(0);
      endif
    endfor

    This tells you the length of the queued tasks for every programmer on
    your moo.  (Natch it's spammy).  The one that gets out-of-seconds
    printed after its about-to-do is your culprit.  Of course, if you're
    having to do this, you can't use @kill, since it iterates over
    queued_tasks(), and the point is that you couldn't use that.  Which
    means you have to crawl through their @audit hoping to find the verb
    in question, disable it in some way that causes each existing fork to
    get an error and therefore exit.  I have in the past had to resort to
    putting an error inside a $string_utils function in order to stop a
    forkbomb.  (I can't remember the circumstances.)

    Obviously you deprogrammer, newt, and maybe redlist while you're doing
    all this investigatory work.  LambdaMOO has some facility to restrict
    the MOO to only wizard logins; I don't remember the precise details,
    it's in $login somewhere.  You can look at the latest core.  As soon
    as the forks are all gone, @shutdown to get a checkpoint -- you've
    chewed up so much VM that you aren't going to be able to checkpoint
    normally.

          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