compatibility bug with litespeed's PHP build (SAPI)

Discussion in 'PHP' started by aww, Dec 31, 2011.

  1. aww

    aww Well-Known Member

    I believe I have run into a compatibility bug with litespeed's SAPI when using a matching build of the cpanel PHP for apache

    PHP can be executed from the command line of course - we use this for various reasons, typically in cron to execute things like WordPress maintenance and avoid wasteful use of the webserver

    When litespeed's PHP is run from the command-line, I discovered at least two problems, there may be more - and I suspect it's from SAPI not falling back when it cannot discover a litespeed parent?

    First, it doesn't match how apache's PHP calculates/recognizes the locally executing script's path as the base for require/include - it assumes the cli path I think, so locally referenced files fail to be found

    Secondly instead of returning null for apache_request_headers, it actually fails entirely, which causes eaccelerator to throw an opcode error and crash.

    This is very easy to reproduce in your lab.

    Just make sure you have a working WordPress install and go to shell, move to a directory outside of WordPress itself.

    Then compare:

    (apache's php called directly, loading wordpress index.php directly)
    /usr/bin/php /home/username/public_html/index.php
    (works - full page output, etc.)

    (litespeed's php called directly, loading wordpress index.php directly)
    /usr/local/lsws/fcgi-bin/lsphp5 /home/username/public_html/index.php
    fails, because it cannot find the proper local path for require like apache's php handles

    Warning: require(./wp-blog-header.php): failed to open stream: No such file or directory in /home/username/public_html/index.php on line 17
    Fatal error: require(): Failed opening required './wp-blog-header.php' (include_path='.:/usr/lib/php:/usr/local/lib/php'

    now we make it work by forcing the directory
    cd /home/username/public_html/ && /usr/local/lsws/fcgi-bin/lsphp5 /home/username/public_html/index.php
    this time it fails because of the SAPI fails to find the litespeed parent and doesn't fail gracefully?
    [30508] EACCELERATOR: PHP crashed on opline 8 of apache_request_headers() at /home/username/public_html/wp-content/plugins/wp-super-cache/wp-cache-phase1.php:450
    Segmentation fault (core dumped)
    Now if you are asking why not just use cpanel's apache's php, it's because it cannot access the shared memory that eaccelerator uses for litespeed's copy of php. This means each of the scripts already in the cache have to be re-compiled and that's very wasteful.
    Last edited: Dec 31, 2011
  2. mistwang

    mistwang LiteSpeed Staff

    the crash has been fixed in lsapi_main.c, please try rebuild you lsphp5 binary. PHP LSAPI packages has been updated.
    The reason why it does not do a chdir like cli-php will take more time to figure out.
  3. aww

    aww Well-Known Member

    Thanks for the quick fix - will have to build much later tonight because it's an active server and can't risk the loads.

    At first I didn't think that PHP does a chdir to the executing script's directory but I guess it does since wordpress tries to use require('./wp-load.php') which implies a local directory, and it works from apache's version.

    Does the "Build Matching PHP Binary" auto-download the newest LSAPI or should I manually replace it somewhere first?

    (by the way 4.1.10 definitely fixes the supercache gzip problem, many thanks)
    Last edited: Dec 31, 2011

Share This Page