stderr.log and LSAPI core dumps

Discussion in 'Install/Configuration' started by dreamscape, Feb 11, 2007.

  1. dreamscape

    dreamscape Active Member

    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.

  2. mistwang

    mistwang LiteSpeed Staff

    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.
  3. dreamscape

    dreamscape Active Member

    Thanks for the reply mistwang.

    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 ?
  4. mistwang

    mistwang LiteSpeed Staff

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

    dreamscape Active Member

    err, never-mind on this issue. I've figured out what it is from and it is unrelated.
    Last edited: Feb 11, 2007
  6. dreamscape

    dreamscape Active Member

    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" ??
    Last edited: Feb 11, 2007
  7. mistwang

    mistwang LiteSpeed Staff

    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?
  8. dreamscape

    dreamscape Active Member

    Yep it sure is.

    Increased them to 60 and 120 respectively.

    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.
  9. mistwang

    mistwang LiteSpeed Staff

    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.
  10. dreamscape

    dreamscape Active Member

    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 :)
    Last edited: Feb 12, 2007

Share This Page