php/lsapi crash since 5.2.9

[jrmarino]

Hi, my solaris 10 and openSolaris (nevada) servers have been running php 5.2.8 for a year using lsapi 4.8.

Today I attempted to upgrade php to 5.2.12. I also tried to upgrade to lsapi 5.0. The php file runs fine in "cli" mode, but it crashes when spawned. I'd seen this before, it was caused by one of the extensions and I just removed it. But I need all the extensions, so I need to know how to figure out what's causing this lsapi crash. I don't know what logs to look at.

I built all the releases, here are the results:

php 5.2.8 with lsapi 4.8 -- works
php 5.2.8 with lsapi 5.0 -- works
php 5.2.9 with lsapi 5.0 -- works
php 5.2.10 with lsapi 5.0 -- crashes
php 5.2.11 with lsapi 5.0 -- crashes
php 5.2.12 with lsapi 4.8 -- crashes
php 5.2.12 with lsapi 5.0 -- crashes

Please help. This has been a fairly frequent issue with the php executable that I compile, and I'd like to be able to upgrade to the latest version of php.

 

[mistwang]

Please try lsapi 5.1
http://www.litespeedtech.com/support/forum/showthread.php?p=18063#post18063
If it still crashes, use lsapi 4.9

 

[jrmarino]

mistwang, I'd like to try this, but the instructions in post 18063 don't seem to apply to me.

I'm compiling PHP from scratch, using the PHP source code and putting the "litespeed" directory in the sapi directory of PHP, and compiling "--with-litespeed". I have never used lsws for building PHP.

Given that, I don't know how to turn on version 5.1 during compilation since I don't use the "buildconf.inc.php" file.

 

[NiteWave]

for manual build, if sapi/litespeed is lsapi 5.1, that's OK.

buildconf.inc.php is used by lsws web admin console to build php.

 

[jrmarino]

Well, I don't have the source code for LSAPI 5.1.

Where can I download it?

 

[jrmarino]

Oh, I see the downloads page was updated yesterday with version 5.1. It wasn't there in the morning.

That was my confusion -- you were talking about 5.1 when it didn't seem to be generally available!

 

[jrmarino]

Okay, I compiled 5.2.12 with LSAPI 5.1

No luck.
When I spawn lsapi, the lsphp process stays up. But as soon as I start the webserver, the lsphp process crashes. I'm using LSWS 3.3.23

 

[mistwang]

Do you use any opcode cache like eaccelerator? you may need to disable it with 5.2.12 .

 

[jrmarino]

I use APC with solaris 10, but the opensolaris server (my dev server) doesn't have any accelerator. So while APC may cause a crash, it's not causing this one because it's not on the server.

Is there any way to narrow down which extension is causing the crash (other than compiling dozens of times by removing extensions)? Is there any way to turn on any kind of logging or dump that could help you out?

 

[mistwang]

If you can make lsphp5 dump a core file, it will help.
You need to add LSAPI_ALLOW_CORE_DUMP in lsphp5 env.
http://www.litespeedtech.com/php-litespeed-sapi.html

ulimit -c should be high enough, the user that PHP run as should be able to write to that directory. And use "coreadm" command to manage core dump.

 

[jrmarino]

Sorry, I can't get it to dump.
It crashes before it gets to running a PHP script.
If I start spawning first, it runs until I start litespeed. If I start litespeed first, and then spawn, it appears to crash immediately.

 

[jrmarino]

FYI, I got these messages during the "make install" process:

make: Warning: Too many rules defined for target sapi/litespeed/lsapi_main.lo
make: Warning: Too many rules defined for target sapi/litespeed/lsapilib.lo
make: Warning: Too many rules defined for target sapi/litespeed/php

I don't recall these coming up yesterday.

 

[mistwang]

We tried PHP 5.2.12 + LSAPI 5.1 in our Solaris 10u2 VM, with option "--disable-all", seems working fine, phpinfo() page load fine.

 

[jrmarino]

I don't have such luck.

phpinfo()
PHP Version => 5.2.12

System => SunOS polaris 5.11 snv_130 i86pc
Build Date => Jan 18 2010 17:42:46
Configure Command => './configure' '--prefix=/opt/csw' '--with-layout=GNU' '--enable-memory-limit' '--program-prefix=' '--disable-cli' '--with-litespeed' '--disable-all'
Server API => LiteSpeed V5.1

That's the command line output of ./lsphp -i, but it won't run inside litespeed.
Maybe there's a library difference causing this? Are you aware of any increased requirements between 5.2.9 (the last version that works for me) and later versions of php?

 

[mistwang]

change configuration of lsphp5 to "Run on start up". so, when LSWS starts it will run lsphp5 immediately without sending any request.
Then you can "strace" or "truss" the process to find out what happened. You can need to add option to follow child process.

 

[jrmarino]

Do you mean to turn off the spawning and have litespeed control lsphp?
I'm not very familiar with strace or truss, you're starting to get outside my realm of capability unfortunately...

 

[mistwang]

If you use a third party FCGI spawner, then that's fine. you can strace/truss the running lsphp5 process, make sure to add parameter to follow child process in command line.
strace/truss just show the system call made by the process, nothing fancy.

 

[piper]

Experience the same thing, XCACHE, SUHOSIN, 5.3.1, LSAPI 5.1

Load usually stays around 1.x to 2.x, but since upgrade it goes up to 4.x to 6.x

Switch back to PHP 5.2.9 and LSAPI 5.1, XCACHE, SUHOSIN, load dropped again to 1.x and 2.x

Litespeed crashed randomly using PHP 5.3.1

 

[mistwang]

I think PHP 5.3.1 is too new to be as stable. No something really wrong in LiteSpeed.

 

[jrmarino]

If you use a third party FCGI spawner, then that's fine. you can strace/truss the running lsphp5 process, make sure to add parameter to follow child process in command line.
strace/truss just show the system call made by the process, nothing fancy.

Hi Mistwang, I tried "Truss" on opensolaris with -f child follow option. This output doesn't tell me anything, how about you? It was polling the spawned process fine until I started LSWS and tried to access a php page.

5758: nanosleep(0x08047B48, 0x00000000) = 0
5758: pollsys(0x08047AB0, 1, 0x08047B38, 0x00000000) = 1
5758: accept(0, 0x08047AD0, 0x08047ACC, SOV_DEFAULT) = 4
5758: forkx(0) = 5787
5787: forkx() (returning as child ...) = 5758
5758: lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000) = 0xFFBFFEFF [0x0000FFFF]
5758: time() = 1265324943
5787: getpid() = 5787 [5758]
5758: close(4) = 0
5787: lwp_self() = 1
5758: time() = 1265324943
5787: lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000) = 0xFFBFFEFF [0x0000FFFF]
5787: getpid() = 5787 [5758]
5787: fcntl(4, F_GETFL) = 130
5787: fcntl(4, F_SETFL, FWRITE) = 0
5787: schedctl() = 0xFEA56000
5787: sigaction(SIGCLD, 0x08047B10, 0x00000000) = 0
5787: sigaction(SIGTERM, 0x08047B10, 0x00000000) = 0
5787: sigaction(SIGQUIT, 0x08047B10, 0x00000000) = 0
5787: sigaction(SIGINT, 0x08047B10, 0x00000000) = 0
5787: sigaction(SIGUSR1, 0x08047B10, 0x00000000) = 0
5787: time() = 1265324943
5787: pollsys(0x08047C20, 1, 0x08047CC8, 0x00000000) = 1
5787: brk(0x08755490) = 0
5787: brk(0x08757490) = 0
5787: read(4, " L S01\09B07\0\0C304\0\0".., 8192) = 1947
5787: close(4) = 0
5758: pollsys(0x08047AB0, 1, 0x08047B38, 0x00000000) = 1
5787: pollsys(0x08047C40, 1, 0x08047CC8, 0x00000000) = 1
5787: accept(0, 0x08047C60, 0x08047C5C, SOV_DEFAULT) = 4
5787: fcntl(4, F_GETFL) = 130
5787: fcntl(4, F_SETFL, FWRITE) = 0
5787: pollsys(0x08047C20, 1, 0x08047CC8, 0x00000000) = 1
5787: read(4, " L S01\09B07\0\0C304\0\0".., 8192) = 1947
5787: close(4) = 0
5787: pollsys(0x08047C40, 1, 0x08047CC8, 0x00000000) = 1
5787: accept(0, 0x08047C60, 0x08047C5C, SOV_DEFAULT) = 4
5787: fcntl(4, F_GETFL) = 130
5787: fcntl(4, F_SETFL, FWRITE) = 0
5787: pollsys(0x08047C20, 1, 0x08047CC8, 0x00000000) = 1
5787: read(4, " L S01\09B07\0\0C304\0\0".., 8192) = 1947
5787: close(4) = 0
5758: nanosleep(0x08047B48, 0x00000000) = 0
5758: pollsys(0x08047AB0, 1, 0x08047B38, 0x00000000) = 0
5758: time() = 1265324943
5787: pollsys(0x08047C40, 1, 0x08047CC8, 0x00000000) = 0
5787: getpid() = 5787 [5758]
5758: pollsys(0x08047AB0, 1, 0x08047B38, 0x00000000) = 0