Search results

It is in "gcc-c++" package. Just try "g++" from command line see if it works. Make sure you have installed 64bit curl-devel package

You can also try adding "--with-libdir=lib64" configuration option.

Have you installed "g++"?

We will update LiteSpeed SAPI code to address this as well.

Yes, it should work. each lshttpd process will start its own group of lsphp processes.

<Files> should work in .htaccess as well.

"core" or "core.*"

sorry, should be php_output_end_all()

Should replace php_end_ob_buffers() with php_end_ob_buffers() for PHP 6.

Try header add in .htaccess, if the whole directory hold wmv, get rid of the "<files...>"

Is there any core file under /tmp/lshttpd? send them to us.

The configuration in the first post should work with latest 3.3.16 build. The "Header" directive was not supported.

The kernel will apply the limit to a process by counting the total number of processes running as that user. The process limits configured at server level is using with start awstats process.

The problem is mainly caused by high I/O wait due to more than 20,000 core files under /usr/local/apache/htdoc/mrtg/ directory. After removing those core files, the server run pretty smooth. If notice more problem just let me know.

Maybe you need to increase the "Process Soft/Hard limit", it may cause fork() to fail.

The same rule works with LSWS.

Core file generated by non-debug build of lshttpd is not useful, should delete those core files after switching to the debug build. Debug build has the debug symbol, have negligible impact on performance of the server.

switch to the debug build, then check core file under /tmp/lshttpd/ or /tmp/lshttpd/bak_cores/, send us the core file. Let us know which version of MacOS are you using.

We have noticed the "failed to start listener on address *:7080" problem on one server, we will have it addressed in 3.3.16. But the 100% cpu of lshttpd is something else, if you notice that again, please strace it, then "kill -USR2 <pid_of_100%_CPU_lshttpd>" to turn on debug logging, let it...

It is because the request has been redirect to /error404.html twice. Does /error404.html exist? Maybe create a /error403.html exactly same as the 404 page, and set 403 error page to that one.