Problem with LSAPI 1.8/PHP in 2.1.11?

[jburks725]

I just updated to 2.1.11 and all of my PHP apps are returning 503. It's starting lsphp, but nothing is working. I was using a hand-compiled php 5.0.5 with the 1.8 litespeed universal patch. I thought maybe I did something wrong in the compile, so I tried copying the admin_php binary that came with 2.1.11 to the server's fcgi-bin directory and using that as lsphp, and I still get the same problem. Logging into the admin console works just fine, so there seems to be a difference in the way that the normal server processes use LSAPI versus the admin console. I turned on debug logging and don't see anything useful.

I reverted to my copy of php 5.0.5 that was compiled with universal patch 1.7 and it seems to work just fine. I see that the differences between the two are quite minimal (just another error check in the library file), so I'm hoping it's safe to run 1.7 for a while. Please let me know what's going on here.

I'm running LiteSpeed on Debian with a 2.6.12 kernel.

 

[mistwang]

I think it is because the opcode cache does not match PHP release, turn off the opcode cache should fix it. you need to compile opcode cache as well.

 

[jburks725]

Hmm...I'll try it again, but I don't think that's it. It was the same PHP release, all I did was make clean, remove the old sapi/litespeed, extract the new one, and then the touch ac*, buildconf --force, configure, make sequence. As nothing else changed by the files in sapi/litespeed, I didn't think it was necessary to recompile eAccelerator. I'll let you know what happens tonight though.

 

[xing]

jb, I cannot reproduce this problem.

Did a clean compile of php 5.1.2 with lsapi 1.8 and overwrote an existing installation of php 5.1.2 with lsapi 1.7 on a live server. No problems.

Perhaps downloading a clean php source and recompiling from scratch will help. I have had problems in the past where even make clean did not clean out all the files from prior config.