Search results

I think that PHP process cannot access the script file, you need to double check the permission of those PHP scripts.

Please try ia32-libs.

If you start the server with root account, LSWS will do that for you. If you start the server with 'nobody', you need to change /etc/security/limits.conf . http://www.litespeedtech.com/docs/HowTo_QA.html#qa_incfd Update: The document is moved to http://www.litespeedtech.com/how-tos.html#qa_incfd

There is vhost level symbolic link configuration which will override the server level configuration. Please click "virtual hosts" link on the left then Click "Edit" action for your vhost.

That's normal, as LSWS now only process matching context when there is no explicit direct match. So, in your case, the matching context has no effect. Normal contexts have high priority than matching contexts. With current release, you have to use normal contexts for those files like /css/...

I don't think lsws has anything to do with the cache memory, it is completely controled by OS Kernel. It should be the kernel. Please upgrade to 2.1.4, as 2.1.3 might have problem with PHP due to insufficient default resource limit configuration.

We will adjust this limit automatically to 3 * Max connections + spare for each external application if the default value is lower than this in new release.

Yes, you are right. probably should not do that. :-) Anyway, will release a new release to adjust the limit to a more propriate value for each external application automatically.

PHP failure is caused by code changes in 2.1.3 which enforce "Process Limit" for FCGI/LSAPI applications. Please increase the server wide "Process Soft/Hard Limit" under "Server"->"Security"->"CGI Resource Control" or override the server wide value with individual external application level...

No, there is not. ;-) We did that for security reason, as user with lower id might be used by the system with a special privilege, so we want to make sure that those users cannot be used for web hosting by accidient. Maybe 50 is not a good chooice, we will lower it in next release to maybe 10...

OK, I knew what's wrong. You need to increase server wide Process soft/hard limit under "server"->"Security"->"CGI Resource Contorl" or per external application level settings added in 2.1.3 . Process limit was not enforced for FCGI and LSAPI application in earlier releases. :-)

Thanks Thomas. Is the php-5.0.5 with LSAPI or FastCGI? With PHP_xxx_CHILDREN environment or not? Please set "Log Level" to DEBUG at server level and the testing vhost.

OK, we will remove the trailing '/' in new release.

If this problem can be fixed this way, we will stop investigating this issue. Thomas, can you please comfirm that graceful restart from admin interface still works properly with 2.1.3. Thanks!

We will change the default behavior to enable scripting when it is not set. Answer to you other questions, "Allow all' is the default, maybe it is because scripting is disabled? yes, that's a issue when relative path is given, should be fixed. The configuration file must be writeable...

Like Thomas said, that's normal if you configured PHP like that. If you want LSWS spawns LSAPI PHP processes on demand, you can remove PHP_LSAPI_CHILDREN=300, and set Instances to 300, but one drawback with this thought, each PHP process will create it own shared memory for opcode cache...

I need more information to trouble shoot this, like: OS: PHP accelerator used: Memory used for opcode cache: Resource limit setting for CGI scripts: Which level the PHP external app being defined, server or vhost? Is the vhost being configured to start CGI in setuid mode? It is better...

There is no known issue with epoll, should be safe to use it in production. Epoll has advantage over poll only when concurrent level is high, otherwise, you will not see big differences.

8K is the best setting for LSAPI.

You don't have to define a vhost level script handler when a server level script handler exists. It will take a little while to become familiar with all the configuration settings. :-)