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)
(works - full page output, etc.)
(litespeed's php called directly, loading wordpress index.php directly)
fails, because it cannot find the proper local path for require like apache's php handles
now we make it work by forcing the directory
this time it fails because of the SAPI fails to find the litespeed parent and doesn't fail gracefully?
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.
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)
Code:
/usr/bin/php /home/username/public_html/index.php(litespeed's php called directly, loading wordpress index.php directly)
Code:
/usr/local/lsws/fcgi-bin/lsphp5 /home/username/public_html/index.php
Code:
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
Code:
cd /home/username/public_html/ && /usr/local/lsws/fcgi-bin/lsphp5 /home/username/public_html/index.php
Code:
[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)
Last edited: