Search results

use GDB "bt" command to get the full stack trace.

Likely produced by PHP processes. better check it with GDB to find out what causing it. yum install gdb gdb /usr/local/lsws/fcgi-bin/lsphp5 <core_file_name> bt maybe submit a bug report to PHP group. If "LSAPI_ALLOW_CORE_DUMP" is set for lsphp5 external app, you can remove it, it can prevent...

yum install gdb then gdb /usr/local/lsws/bin/lshttpd <path_to_core_file> bt it will list the call stack back traces.

We have seen something like that when PCRE goes into a infinity loop. Maybe you should load the debug build of LSWS. When it happens, strace the lshttpd process using too much CPU first, then send "SIGBUS" to that process with command kill -BUS <pid_of_lshttpd> It will create a core dump in...

with LSWS 4.0.20, change header() code or add a new one header('X-LiteSpeed-Cache-Control: no-cache' ); it will prevent LSWS from caching this page.

You need to build the jail environment for the script, otherwise, it wont work. If you want per account chroot, you may have to use Cloud Linux SecureLVE, otherwise, it is pretty hard to maintain the chroot jail. Our 4.0.20 release should support SecureLVE on plain centos.

http://www.litespeedtech.com/support/wiki/doku.php?id=litespeed_wiki:php:lsapi:troubleshoot for any missing package, just do "apt-get install <package_name>".

Please download 4.0.20 again, changed the code to 500.

You should notice that each log entry has a different port number 2161, 2176, 2189, 2204, it means that the client you use for this test was resending the same request repeatedly, if the same request being restarted multiple times, the port number will stay the same.

You need to find out what causes the memory problem. you have to find it out in order to fix it. varnish may use memory for their cache storage, consume available memory. LiteSpeed cache use HD as storage, linux kernel should be smart enough to manage I/O buffer memory without causing trouble...

Please try again, upgraded your LSWS to 4.0.20 .

Reduce "Max Connections" for lsphp5 external app or, "PHP suEXEC max conn" if use PHP suEXEC. Use LiteSpeed internal page cache should give you better performance than varnish. http://www.litespeedtech.com/support/forum/showthread.php?t=4679

looking for errors in error.log, stderr.log and dedicate PHP error_log

probably not, recompile is the easiest, should not cause down time.

open_basedir works with lsphp, just like with mod_php. Just override open_basedir with php_admin_value in the vhost configuration. that's the way cPanel generate the vhost configurations.

This is request from another user, the request was assigned to a run away PHP process (stuck with the long MySQL query, maybe). It has to be retried with another good PHP process, it has nothing to do with the second SQL you observed. You should only look for your IP for anything related to...

And you should rebuild PHP with latest LSAPI v5.5

if "LSAPI_ACCEPT_NOTIFY" env is set in your lsphp5 external app configuration, you need to remove it.

http://www.litespeedtech.com/support/forum/showthread.php?t=1082

Please download and try 4.0.20 build, we add some logic to avoid that. Just change version number in the download link.