So yet another thing about having one’s own private virtual world is that one can do all sorts of fun but dangerous stuff that one wouldn’t do in anyone else’s.
The main fun-but-dangerous thing, naturally, being the creation of uncontrolled replicators.
(Carefully controlled replicators are safe even for, say, Second Life; and of course SL has the Grey Goo Fence, which is good for the Grid but can be annoying for Residents.)
The other day in my local OpenSim-on-a-stick I made a little physical sphere that randomly moves around. It promptly took off into the open water ‘way off the side of the sim (into space that, strictly speaking, doesn’t exist).
So then I made a tall green wall, and put the randomly-moving ball inside the wall, and that was better.
Then I taught the ball to make copies of itself, and also to randomly delete itself. I set the probability of replicating just barely above the probability of self-deletion, knowing from my days as an Anti-Virus Guru that this should lead to an (initially) slow population increase.
Then I got bored, watching the number of balls inside the wall go from one to two to three, back to two, back to three, to four, back to one…
So I cranked up the probability of replication a bit. And then of course the phone rang and I had to open a different window to do something, and when I went back to the viewer:

Oh, dear.
Well, no problem, I thought; the sim was running kind of slow, but I could just cam up, select everything nearby, deselect the wall, and hit Delete.
And that worked great, except that in the few seconds between my selecting everything and hitting Delete, another few dozen balls had spawned, and they weren’t selected or deleted, and then a couple seconds after that the sim was running so slowly that deleting stuff wasn’t really working anymore.
And then I noticed…

a potential crisis! If the balls were to start spawning outside the wall, it seemed not unlikely I would have to restore the sim from the last OAR file I took or something.
On closer investigation there were at least three balls that had apparently escaped the wall:

but when I went to examine (and hopefully quickly Delete them), it turned out none of them actually existed as far as the sim was concerned, the viewer was just confused as a result of all the physics and lag going on. So that was good.
I thought I would log out and then log back in as the AV with Estate powers (Simona Stick, rather than Test User). I noticed that over on the Opensim console, things were not entirely happy:

It look a long time to settle down again when I tried to log out, and at this point I started to panic a bit. In the time it would take me to log in as the estate owner and try to turn off scripts or whatever, would the sim have become utterly unusable? So instead I did a shutdown on the Opensim console. This resulted in lots more red messages for quite awhile…

but eventually it did shut down.
Okay, smartypants, so now what? Well, it turns out that Opensim in Sim on a Stick happens to use a MySQL database to store everything in, and that due to the Day Job I have some knowledge of MySQL, and the database tables that Opensim uses are at least somewhat documented.
So once I’d figured out the MySQL username and password that SOAS had installed, I logged into the MySQL console, and viola:
mysql> select count(*) from prims;
+----------+
| count(*) |
+----------+
| 1482 |
+----------+
1 row in set (0.00 sec)
So we have fourteen hundred and eighty-two prims. Fortunately all of the self-reproducing ones have the same name, and each rezzed prim (as far as I can tell) corresponds to one or more records in just three different tables.
First we delete the shape-records for the prims (Opensim could save considerable space in the database by compressing out duplicates here, one would think):
mysql> delete from primshapes where UUID in (select UUID from prims where name="moving and reproducing ball");
Query OK, 1294 rows affected (0.05 sec)
So it looks like we have about 1294 replicators
Then, we destroy the contents (prim inventories) of all of them:
mysql> delete from primitems where primID in (select UUID from prims where name="moving and reproducing ball");
Query OK, 2385 rows affected (0.14 sec)
And that more or less makes sense; each replicator typically contains a script and a copy of itself, so we’d expect to have roughly twice as many contents as we have replicating prims. 2385 is somewhat less then twice 1294, but that’s because of that “roughly” in the last sentence, which I will not go into in detail.
And finally, we remove the little beggars themselves:
mysql> delete from prims where name="moving and reproducing ball";
Query OK, 1294 rows affected (0.05 sec)
Another reassuring 1294.
Now we would expect to have 1482-1294 prims left, and:
mysql> select count(*) from prims;
+----------+
| count(*) |
+----------+
| 188 |
+----------+
(counting on fingers) that adds up!
Crossing our fingers and venturing back into the world as Test User, we find:

The wall (and everything else) undamaged, but the nasty replicators gone! And sim performance back to normal. So huzzah!
Disclaimer: I have no idea whether the steps above are actually the right way to remove a bunch of nasty things from an OpenSim instance, and for all I know they have left the database in some incoherent state that will cause it to die horribly tomorrow. If your Opensim world is valuable to you, take frequent backups and don’t go messing with the database directly in MySQL because of something you saw in a weblog once. Also, in retrospect, it probably would have been cleverer to use MySQL just to turn off scripting for the estate, and then gone in and cleaned up normally inworld. But hindsight is a penny earned!
Filed under: Other worlds, scripting | Tagged: mysql, OpenSim, replicators | 4 Comments »