Search results

We have fixed it this issue in latest 4.2.4 build based on information collected from another user experiencing similar problem.

Please ask you hosting provider to update to the latest LSWS 4.2.4 build with "Force reinstall", see if it addresses your issue.

can you truncate error_log and stderr.log, set log level at "INFO", restart LSWS, wait for "no data" happen. record the time when it happens, send the log to bug@litespeed... for analysis.

WHM plugin has been updated to address this issue as well. You can do a force reinstall of 4.2.4 to apply the fix.

It is a file timestamp problem. Please do from command line to fix it.

We need to evaluate this issue in our lab. Please create a test cpanel account to reproduce this issue, then create a backup of the account, send us the backup, so we can import it to our internal cPanel test server for investigation. You can contact us via PM or email to bug@litespeed...

Are you using PHP suEXEC daemon mode? Sounds like something wrong with shared opcode cache. 4.2.4 should log the reason why PHP processes die if they are crashed, just set log level at "info". To let PHP dump core files, you need to set "LSAPI_ALLOW_CORE_DUMP" env to lsphp5 external app...

So, you removed soft/hard memory limit for lsphp5 extapp ?

there is a memory limit in php.ini as well.

issue fixed with latest 4.2.4 build. please do a force reinstall from web console or with command /usr/local/lsws/admin/misc/lsup.sh -f -v 4.2.4

With CloudLinux, you have to enable "PHP suEXEC". If you do not use per-user php.ini, you can use PHP suEXEC daemon mode. The default setting is good.

http://www.litespeedtech.com/docs/webserver/config/extapps/#memSoftLimit

Maybe you forgot to update cagfs skeleton after updating php.ini, if you use CloundLinux. Always check the limit from php.ini with phpinfo() page.

Or, you can enable mod_security audit log, and send us the log related.

We will try the request data in the log first. maybe it will work.

Also we need the whole request trigger it. The easiest way is to use chrome tools->"Developer Tool". click "network" tab. locate the request url, right click, then select "Copy as cURL". paste it to a text file, then send it to us. It does not matter the offending rule has been commented out...

We could not reproduced it with the logged data. Do you or your client know which request causeing this. If this can be reproduced, please capture the request data for us. The easiest way is to use chrome tools->"Developer Tool". click "network" tab. locate the request url, right click, then...

Yes, please send a copy of 01_asl_content.conf to bug@litespeed... or attach to a PM to me.

It is caused by a bug in early release of lsapi 6.3. fixed now. Please build lsphp53 again with latest lsapi 6.3. If you use litespeed console to build it. you should remove /usr/local/lsws/phpbuild/php-litespeed-6.3.tgz then build again.

The segfault might be due to a bug temporarily introduced into php-litespeed-6.3 package. just remove /home/cpeasyapache/ls.src/php-litespeed-6.3.tgz then build matching PHP again, it should take care of it. Next release we will move APVH_* socket address to something like /dev/shm/lshttpd .