Multiple instances of script running

Shared hosting disabled site

[salewit]

I run a relatively small website on a shared hosting service. The other day I found my site was disabled, and when I contacted my host provider, they said it was disabled because multiple instances of the same php script was crippling the server. It is a script that I wrote, and I spent hours checking it out, but can't see any problems. Any ideas what causes a script NOT to end?

Here's the message I got from the host:

Your account is running multiple instances of several php scripts and causing major problem for the entire server. We have been monitoring this for the last couple of hours. After carefully watching the server hardware consumption at the time when the load increases and server performance decreases, we have identified that your account is the one causing problems on the server.

[coopster]

Any ideas what causes a script NOT to end?

Poorly constructed loops (control structures) are typically the culprits.

[penders]

Your account is running multiple instances of several php scripts and causing major problem for the entire server.

Presumably every visitor to your site runs their own instance of your script? Busy site = many instances of your script?

[salewit]

See that's what I was wondering, because the script only has 2 loops in it and they are so straightforward I just can't see any problems that would occur.

This particular script takes a comment and stores it in a MySQL file. What I did discover yesterday by looking at the logs (something I rarely do) was that I was being bombarded with hits from Russian and French sites. Given that this is a local site I figured this to be the problem. At one time this script was wide open to comments. I've since added a decent Captcha to it, but I think it's still being hit, so I'm guessing this may be the cause of the "popularity".

Thanks for the help.

[rocknbil]

Really sounds like your problem stems from an attack, not a code fault. But just the same:

One thing I seldom see

mysql_free_result($result);

immediately after any query frees the memory used by that query. True, this may be minor, but like the difference between a 50K image and a 20K image, it all adds up.

You can also add memory_get_usage() [us3.php.net] throughout your script at key points, and store them in a file. Example:

$total_usage = "opening DB . " memory_get_usage()";
// do your select
$total_usage .= " after DB " . memory_get_usage();

Then at the end, open a log file and store it so it runs "transparently."

The explain keyword in your mysql statements themselves can help optimize your queries.

I've since added a decent Captcha to it, but I think it's still being hit, so I'm guessing this may be the cause of the "popularity".

Captchas can be beaten by robots, I know this to be fact and have seen it in action. I don't know how they do it, or why, I just know they can. The reason for your popularity, and the reason they persist in spite of the captcha, is that there is something else your script does that they want to abuse.

Since you haven't revealed the nature of the script, let's just say it's a mailer (or worse, something that writes to a database.) If not properly filtered, input data can abuse mail headers to do something like this:

to: [e-mail], [e-mail], [e-mail],.... X 1000

Got that one plugged? Here's another. Using encoded octal characters instead of the newline I'm showing you for example, they do this:

to: [e-mail]\nBCC:[e-mail], [e-mail],.... X 1000

But you say "My mailer doesn't have a BCC header." You don't need to. They just created their own BCC header.

You get one spam mail. Example.com gets 1000. Poof, you're on example.com's blacklist.

A third is to inject a multi-part header into the body of the mail so it doesn't matter WHAT gibberish goes in the email, the multipart is a full second email being mailed to any number of recipients and can contain virus attachments.

This is one micro-examination of a scenario in which spammers/hackers are motivated to abuse your scripts. Look into it; filter user input data like the poison it is, throw anything away that is not the model of your expected input. Basically take away the reason for abusing your script, and you won't need to add a barrier to your legitimate users by using captcha.