Support

SyNeo · #11 09-02-2005, 11:30 AM

Quote:

Should a plain restart of the server enable these restrictions?

It is a OS wide configuration, probably need a reboot. I am not sure. Can you apply the limit from command line any way.

Quote:

Are the instructions of modifying the cgi_main.c are still valid for the PHP5 as well?

Yes, it is still vaild.

xinn · #12 09-04-2005, 08:18 AM

Im still getting this 503 errors.. Should i raise any limits ( f/e Max Connection)? and is there a constant value for how long this error will stay?

Regards

xing · #13 09-04-2005, 10:07 AM

Raising limits will not help you situation. The most common reason for the 503 errors if your php processes crashing or taking so long to process they might as be considered zombies.

You need to monitor stderr.log, error.log, or php.err for any php related errors. In addition, we might be able to help you if you provide the actual code to the script causing the problem.

Also check for any core.XXXX files within your php file directory or within /tmp/lshttpd/.

mistwang · #14 09-04-2005, 10:16 AM

Another not so good temp solution, restart lsws automatically from a corn job once for a while. This way no service interruption at all.

Have you tried LSAPI again?

We certainly need more information about your server, maybe the login to the admin interface, if you don't mind. :-)

SyNeo · #15 09-06-2005, 02:29 PM

Hi.

I think I discovered another issue, related to the memory leak. My site application throws here and there the following error:

Fatal Error
[2] gzcompress() [function.gzcompress]: insufficient memory (@line 204 in file /var/myndweb/common/framework/TViewStateManager.php).

Debug Backtrace
#1 TViewStateManager.php:204 -- pradoErrorHandler(...)
#2 TViewStateManager.php:204 -- gzcompress(...)
#3 TPage.php:374 -- TViewStateManager->encode(...)
#4 TPage.php:957 -- AllUsers->savePageStateToPersistenceMedium(...)
#5 TApplication.php:481 -- AllUsers->execute()
#6 index.php:27 -- TApplication->run()

A restart of the server allows to resolve the issue, but only temporary. I'm using the LSAPI.

This behavior is not spotted in Apache.

The suggestion to restart the server seems interesting, but won't it destory the server side sessions, and will cause a mess with the applications?

mistwang · #16 09-06-2005, 03:32 PM

Maybe the memory limit for PHP process is too low, you can increase the limit under "Server"->"Security"->"CGI Resource Control". It controls the memory limit for FCGI and LSAPI app as well.

Usually PHP store session data on disk, restart lshttpd will not affect PHP sessions.

SyNeo · #17 09-07-2005, 07:13 AM

Hi.

Any recommeded values that I can try?

Also, the "CGI Daemon Socket" is set to N/A - should it be set to some path?

mistwang · #18 09-07-2005, 08:14 AM

You can try current value + 10M.
CGI Daemon Socket can be set at will, default is set to $SERVER_ROOT/admin/conf/cgid.sock. Will make it optional.

mistwang · #19 09-07-2005, 01:39 PM

Please download 2.1RC3 package again, there are small bug fixes, and one new feature for debuging. Debug logging can be dynamically turned on and off through web admin interface.

So, when 503 error happened, please remove current error.log, turn on debug logging for a little while before restarting the server, then email us the error log file, it will help analyzing the problem a lot.

SyNeo · #20 09-27-2005, 02:16 AM

Hi.

I wanted to update you that I switched to FastCGI, and never had any problems since then, including using the eAccelerator with optimizer turned on. I would like to switch to LSApi thought, the question is whether this issue was resolved in the latest release version (2.1.1).