Search results

from Apache configuration file or native configuration in LSWS admin console?

please wait our update build of 4.0b1 to include a few recent bug fixes.

should be OK with the latest build.

We aware of the improvement in FreeBSD7, if our FreeBSD6 package breaks on FreeBSD7 we will start to offer dedicate package for FreeBSD7. It only require creating a few symbolic links for libc.so libcrypt.so libm.so to use our FreeBSD6 package on the 7.

Are you using Include in a .htaccess?

OK, the problem has been fixed. It is because that there are about 300 IP configured. I have updated it to the latest 3.3.11 build.

It is very hard for us as we have no experience with this kind of setup, and it cannot guarantee that we can reproduce it this way. I think the best way to trouble shoot this, if it is OK with you, we can login to your server and debug it under GDB. Have you tried the standard edition? I...

Please send me the core file generated by the 6.2 debug build. I will check.

what is your "ulimit -a" output? I wonder if it is a stack/heap overflow problem.

It won't work as the admin console run its own PHP instance.

It is better to have a dedicate domain name for each backend node for trouble shooting purpose.

Yes, that's correct.

try removing it and build again.

remove "--with-apxs2" configuration parameter.

Make sure you are using lsws/fcgi-bin/lsphp5 for the lsphp external app. PHP binary should be installed to lsws/fcgi-bin/lsphp-5.2.5, please check the timestamp.

Please try http://www.litespeedtech.com/packages/3.0/lsws-3.3.11-ent-i386-freebsd62.tar.gz

It is a PHP internal problem. You can try GDB the PHP process as well. gdb /home/lsws/fcgi-bin/lsphp5 <pid_of_lsphp> (gdb) cont Then send the problemtic request, gdb will stop at the crash point, then type command "bt" from gdb. It shows you PHP crash point, with this information you should...

It might be a memory limt problem. You can try increase the memory soft/hard limit for lsphp external app. If it deos not help, you may have to rebuild you PHP binary again matching the configuration parameters used by Apache mod_php.

Yes, It will make into the LB, it is hard to predict when it is going to happen right now.

After you start to strace the process, send a request that result in 503 error, strace will dump all system calls involved with processing that request. And you should be able to find out why PHP failed to process that request based on the output.