News
| Lighttpd 1.4.29 | Jul 10, 2011 | Rei |
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
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
Kawaii or NOT?!
Solovan wished Gertrud Barkhorn a Happy Birthday
|
revengeman found a Dragon Slayer Candidate Kuesu Jinguji
|
Genesis02 faved Sumi Sakurasawa
|
Genesis02 loved Eriri Spencer Sawamura
|
|
Genesis02 rated Eriri Spencer Sawamura ★★★★★
|
|
Genesis02 wished Sumi Sakurasawa a Happy Birthday
|
revengeman wished Ringo Oginome a Happy Birthday
|
Clener74 wished Sabo a Happy Birthday
|
Clener74 found a Dragon Slayer Candidate Maya Amano
|
| bprince36 joined |