Disable scripts ... or not?

Hi!

During the last grid attack I became aware of a long-standing problem again. You said, you disabled all scripts grid-wide. Well, I see my tail and ears are not moving anymore, but my Animation Overrider still works. We were watching one of those goo-spawning beach balls, which was happily spitting out goo while other scripts were disabled.

My Question:

Why are some scripts stopped but others still running? What is the mechanics behind this? I notice the same on welcome areas, where scripts are turned off, but still some scripts continue to work. I strongly advocate "No scripts" to be just that "No scripts". So, can you please explain what's happening there?

Thanks for your time!

Hi Zi,

I'm not sure why it would appear that some scripts have been turned off but not others, so I've asked for some input from others who should know the reason. I hope you'll hear back from them shortly.

Some scripted features such as animation override, particle systems, and llTaretOmega() for static content are state changes that are are set by the script and are then cached by other systems, so they don't necessarily require a running script engine to continue in their current state. However most of them do require a running script engine in order to change their state.

As to why a rezzer would function in a region while all other scripts in that same region are off... that would be a bug. Given our success at stopping world-wide expansion of a malicious rezzer I'm skeptical that the bug exists despite your eye-witness account, so I offer the following theory...

I was intimately involved in cleaning up that particular 'beachball' attack that you're talking about and as I recall there was a minor complication that could have produced the effect you're describing, although it isn't clear from your story whether it is the case. The command to disable scripts is communicated to the regions via a config file that is ultimately distributed via a tool called dsh which requires a list of hosts on which to operate (called a dsh group). If the list is not correct, missing an entry or two for example, then the missing hosts will not receive the message. An incorrect list is not too surprising because we have > 1000 machines some of which fall offline or come back on after repairs, so if the list were a few days old then it might not properly reflect the status of the grid .

As I recall when cleaning up a few of the attacks we discovered later that there were missing entries in the 'dsh group'. I had to manually update the list and redistribute the script lockdown or cleanup commands. So I speculate that perhaps you were seeing scripts operating in the neighboring region, which may have been one running on one of the machines missing from the dsh group.

I should mention that we now have a script that will generate a fresh dsh group of simulator node machines, and that it is considered good practice to update the list before trying to send out commands to the live grid.

The distribution of the command to disable scipts requires something less thatn 1 minute to go out to approximately 2000 machines (I think the fork limit is 200 right now), so another possibility is that you were in a region on a machine at the front of the list and were watching rezzing scripts in a region near the end of the list that had not yet received the command. It isn't clear to me how long you watched the rezzing scripts, how long the lockdown had been, or whether they were in the same region as yourself.

Edit to fix some spelling errors.