A post I found on another forum, maybe this thing is worth reading ... there
are 2 parts from this same guy ... read below ...


This might be long but shows something I must have missed ... and I'm sure
the solution is simple

On a Plesk intel sys I am having this serious problem that might affect any
form posting page (years back this was a classic DOS attack but Apache has
patched this ages ago )


Simple php script that does simple select * from (page is a total of 30k so
needs couple of seconds loading). A Form on that page submits on itself.
Pressing regularly the Submit button acts as usual (page returns ok). You
can see the rest ... banging like crasy on that Submit creates a fifo Mysql
Sleep queue and blocks connections with apache .

*** Now wait .. dont answer yet this is tougher than that ***

_pconnect or _connect have the same effect

I placed php non persistent .. the same

Apache keep_alive=Off .. the same

Mysqld variables wait_timeout was reduced (I saw the sleep status by
mysqladmin, and the growing sleep threads). After this timeout the sleep
threads were killed but ressources not freed. Same thig with wait_timeout.

So I got serious ... netstat shows that on every mysql sleep a socket was
opened with the script (thats just the way it should be since a child forks
on the page) but the child stays at TIME_WAIT or some ACK state. Seems as if
apache cant detect closed socket from client (pipe sig or whatever)

* mysqld restart WONT free the connections (it's apache's fault)
* httpd restart does the trick since all blocking children are killed and
the browser behaves as usual (reproducing every time the stuff above)
* mod_throttle also does the trick since I limit to 1 Concurrent
connection.. but that sux

I have been on this for 14 hours now without coffee or sweets , so please
someone tell me the one and only line i have to place in a config file to
resolve this mess



Configs are :

php 4.0.6 (basic Plesk install)

Apache 1.3.19 (Plesk install)
mod_perl, mod_throttle, mod_php4, mod_frontpage, mod_ssl, mod_setenvif,
mod_so, mod_unique_id, mod_usertrack, mod_headers, mod_expires,
mod_cern_meta, mod_proxy, mod_digest, mod_auth_dbm, mod_auth_anon, mod_auth,
mod_access, mod_rewrite, mod_alias, mod_userdir, mod_speling, mod_actions,
mod_imap, mod_asis, mod_cgi, mod_dir, mod_autoindex, mod_include, mod_info,
mod_status, mod_negotiation, mod_mime, mod_mime_magic, mod_log_config,
mod_define, mod_env, mod_vhost_alias, http_core

Mysql 3.23.36


The second post :


I ripped inside out that script and got out of it what follows for people
who want to know :

the _connect is done in an include file, look at the snip here :

print(); // 16k long

The blocking happens with the above


When I make the _connect inside the same script file (without include() ), I
NO longer get the apache blocking but my TCP stack continues growing with
CLOSE_WAIT sockets (one for each reload)... totaly nuts since it's the same
thing as before but mysql does no longer queue sleep threads .. this is

when i reduce that print() of 16k to less (like 1 k)
I NO longer get socket CLOSE_WAITS and all works ok

What it means to me :

Under mod_php if all buffer flushes have not been done before a die()
(another reload) and another apache fork is made (or child select()),
ressources are NOT freed. To make sure of this I placed a
mysql_close();sleep(2) just before the long print().
mod_php had then the time to close much more sockets than if I left the
sleep(2) out.. but still some CLOSE_WAITS were maid.

All this was on IE and Netscape. The problem is as you said, If I get a DOS
attack my comp will die, even worse If I have huge hits since TCP stack will
reach MaxClients and apache will refuse connect().

That's it

PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to