stderr.log and LSAPI core dumps

[dreamscape]

I'm having some kind of issue with the PHP LSAPI module.

It is doing core dumps all over the place in multiple web accounts. I know it is the LSAPI module because if I input the core dumps into bdg it tells me they are created by the PHP LSAPI module. But when I backtrace, the reason is always different. And sometimes the core dumps are not readable by bdg, or are just empty files.

Every time it happens, it seems that the following entry is placed into LiteSpeed's stderr.log:

which: no convert in ((null))

Any ideas what could be going on?

I first installed PHP 5.1.6, and thought perhaps it was a bug, so I upgraded to 5.2.1, but the problem persists. I also thought perhaps it was APC, because I've had some problems with it in the past, so I disabled APC to rule that out as a suspect.

Would appreciate any insight or advise.

Thanks!

 

[mistwang]

I don't think it is a bug in our LSAPI module, should be some where inside PHP.
Since LSAPI SAPI is used, the entry point of PHP is always from our LSAPI module, you have to check the detail backtrace to figured what exactly causes it.

 

[dreamscape]

Thanks for the reply mistwang.

you have to check the detail backtrace to figured what exactly causes it.

That's the only problem: the cause is always something different.

Is the LSAPI module known to be 100% compatible with newer PHP versions such as 5.2 ?

Also, any idea what the "which: no convert in ((null))" entries mean in the LSWS stderr.log ?

 

[mistwang]

Is the LSAPI module known to be 100% compatible with newer PHP versions such as 5.2 ?

Yes.

Also, any idea what the "which: no convert in ((null))" entries mean in the LSWS stderr.log ?

No clue, you can grep the "no convert in" string in PHP source code see if you can find something.

 

[dreamscape]

No clue, you can grep the "no convert in" string in PHP source code see if you can find something.

err, never-mind on this issue. I've figured out what it is from and it is unrelated.

 

[dreamscape]

Ok, the LSAPI PHP core dumps all have this: "Program terminated with signal 24, CPU time limit exceeded."

I'm used to seeing something like "Program terminated with signal 11, Segmentation fault." in a core dump, but "CPU time limit exceeded" ??

 

[mistwang]

Please check output of "ulimit -t", it should be ulimited.
And try to increase "CPU soft Limit" and "CPU hard limit" under "server"->"Security", this limit does not be applied to PHP LSAPI, only apply to plain CGI. But it does not hurt to increase it.
Which version of LSWS are you using?

 

[dreamscape]

Please check output of "ulimit -t", it should be ulimited.

Yep it sure is.

And try to increase "CPU soft Limit" and "CPU hard limit" under "server"->"Security", this limit does not be applied to PHP LSAPI, only apply to plain CGI. But it does not hurt to increase it.

Increased them to 60 and 120 respectively.

Which version of LSWS are you using?

LiteSpeed/2.2.6 Standard
2.4 of the PHP LSAPI module, compiled with PHP 5.2.1

Not sure if it helps, but some other system info is:
CentOS 4.4
Intel Pentium D 820 (2.80GHz)

For the record, I also have LiteSpeed/2.2.6 Standard installed with version 2.4 of the LSAPI and PHP since 5.1.6 (now at 5.2) on localhost (a G4 running OS X 10.4), and have not experienced any of these core dump issues on that set up.

 

[mistwang]

Increased them to 60 and 120 respectively.

60 is 1 minute, maybe try something like 3000. And set "PHP_LSAPI_MAX_REQUESTS" environment variable to something like 500, so a PHP process will exit after processing 500 requests.

 

[dreamscape]

I did have PHP_LSAPI_MAX_REQUESTS set before, and it didn't seem to do anything as the lsphp processes quit rather quickly. Reading the docs, from what I could gather, PHP_LSAPI_MAX_REQUESTS has no effect if lshttpd is parenting the processes, which I have that set up.

I think the problem is resolved as there hasn't been any core dumps in over 12 hours. I believe the problem was a multitude of factors.

First, some core dumps were being caused by the XML RPC php extension, which was weird since it's not even being used by any scripts. So I removed it from PHP, and that solved some of the dumps.

Second, I upgraded the kernel, and that solved some of the other dumps, but still a few persisted.

Third, I increased the CPU soft and hard limits higher than I did before, and that appears to have taken care of the rest of the core dump.

mistwang, thanks for all the assistance.

Yeah