PHP HTTP/503 on Ubuntu 15.10

[kiler129]

Hi!
I've just installed newest LSWS on one of our developers computer. It's also a fresh Ubuntu 15.10 installation with added i386 architecture & installed libz32.
After installing LSWS I compiled PHP7 and created external app entry for it. Unfortunately everytime I visit even simple phpinfo I'm getting 503 with "Connection reset by peer" or "Broken pipe" in logs. I even switched to built-in PHP5.6 and efect is exactly the same.
I double checked memory limit and loaded php.ini (which in fact is not loaded, so default settings are used). Both php5.6 and php7.0 binaries works fine with CLI. Executing lsphp5/7 -i outputs standard informations, so there's no problems with dynamic linked libs or something like that.

Litespeed was installed using default options, except user - I used user and group of local logged-in user instead of nobody:nogroup.

Any ideas?

 

[mistwang]

Sounds like you are running 64bit lsphp binary from 32bit LSWS standard. you need to check stderr.log to found out why it fails.
You may need to compile 32bit lsphp binary.

 

[kiler129]

Actually you're right - both binaries (lsphp5 and lsphp7) are "ELF 64-bit. x86-64", but on our dev server lsphp is also 64bit while lsws is 32-bit.
I looked into stderr.log while opening phpinfo page and I've got only multiple lines saying "fork() failed, please increase process limit: Resource temporally unavailable". Unfortunately only process limit I know of is set using lsws webpanel - I set soft/400 and hard/500 there.

 

[mistwang]

increase the process limit of lsphp5 and lsphp7 external apps.

 

[kiler129]

Do you mean that limits?


They're set pretty high.

 

[mistwang]

Yes, not high enough as there are more processes running as the user that lsphp7 need to run as.

 

[kiler129]

So, to be precise these soft/hard limits are applicable to ALL user processes? I always thought it's a limit of current application (in this case lsphp) forks + 1 (main process).

 

[mistwang]

No. it is tested against the total number of running processes of that user at the moment fork() was called.
Kernel has no clue on how many children processes is going to be started when need to start the main process.