• News
• New
• Index
• About

been using Lighttpd 1.4.29 on the dev site for a few days now.

1.4.28 suffers from an sbwait problem ... basically, if you are using PHP CGI + lighttpd, and a fast_cgi process gets stuck waiting for data to be received by the php-cgi process.

i figured out 3 ways it could happen

1. the firewall could close a connection early
but that was proven impossible, as on each ACK the timer is reset. so even having a 10 second expiration on ESTABLISHED states wouldn't matter if data is ACKed each second since the timer would be constantly reset to 10 sec and could continue on like that all day

2. php max execution time or input time limit
this one possibly is to blame. i know insane sites likely set this to 0 but i prefer 60s. in theory, 16 file uploads limited to 1b/s transfer rates could shut down any default install of lighttpd+php-cgi so to prevent a one man dos, or at least mitigate it.. i like to kill off transfers but possibly in doing so, the TERM doesn't slide up to lighttpd properly.. but it should have a TIME_VAL and sighandler to break the connection

3. lighttp max upload size
also set this low. well if it's triggered, lighttpd send a 4xx status code. so.... not likely to be the cause

lighttpd 1.4.27 was borked on FreeBSD. not gonna run any new release on a production server until it's proven stable by other fools

for the meantime... i'm stuck manually reaping php-cgi processes zombied into an sbwait state

[rei@ai ~/sbwait]$ ps jlaux -U www | grep sbwait
www 3299 58416 58416 58416 0 IJ ?? 0:02.98 /p/bin/php-cgi - 80 0 44 0 27424 8072 sbwait 0.0 0.1 2:59PM
www 91809 58416 58416 58416 0 IJ ?? 0:03.88 /p/bin/php-cgi - 80 0 45 0 27424 8008 sbwait 0.0 0.1 Thu05PM

ai# kill -INT 91809