php/lsapi crash since 5.2.9
- Thread starter jrmarino
- Start date
The OS is opensolaris x86 (32bit)
litespeed version: 3.3.23 std
lsapi version: 5.2 (did not work with 4.8, 4.10, 5.0, or 5.1 either)
php version: 5.2.12
Most of the testing I've done on this 32bit opensolaris (intel). However, I also tried it on 64bit solaris 10 (AMD) with the same results.
As mentioned earlier in this thread, PHP 5.2.9 was the last version that worked, so I don't think it's necessarily a lsapi thing. I am positive that if I recompiled 5.2.12 with lsapi 4.10, it would still not work.
polaris-marino# uname -a
SunOS polaris 5.11 snv_130 i86pc i386 i86pc
SunOS polaris 5.11 snv_130 i86pc i386 i86pc
lsapi version: 5.2 (did not work with 4.8, 4.10, 5.0, or 5.1 either)
php version: 5.2.12
Most of the testing I've done on this 32bit opensolaris (intel). However, I also tried it on 64bit solaris 10 (AMD) with the same results.
As mentioned earlier in this thread, PHP 5.2.9 was the last version that worked, so I don't think it's necessarily a lsapi thing. I am positive that if I recompiled 5.2.12 with lsapi 4.10, it would still not work.
The compiler is gcc 3.4.3
I don't think I should upgrade to 4.0.12 to fix this problem. The reason? Because on my production site, the spawned lsphp processes are shared between 3.3.23-std and 3.3.15-enterprise. I probably could get up to 4.0.12 on the standard server (I already tried but had to drop back down to 3.3.23 due to that follow symlinks permission problem), but I am stuck on 3.3.15 on the enterprise server since my 1-year support ran out. So if upgrading fixes the PHP problem on the std server, it'll break the enterprise server. Hopefully that was clear...both servers use remote external php. The enterprise lsws balances between 2 php servers and the std lsws is actually located on one of the php servers and shares the lsphp children processes.
I don't think I should upgrade to 4.0.12 to fix this problem. The reason? Because on my production site, the spawned lsphp processes are shared between 3.3.23-std and 3.3.15-enterprise. I probably could get up to 4.0.12 on the standard server (I already tried but had to drop back down to 3.3.23 due to that follow symlinks permission problem), but I am stuck on 3.3.15 on the enterprise server since my 1-year support ran out. So if upgrading fixes the PHP problem on the std server, it'll break the enterprise server. Hopefully that was clear...both servers use remote external php. The enterprise lsws balances between 2 php servers and the std lsws is actually located on one of the php servers and shares the lsphp children processes.
Okay, the ancient GCC appears to have been the culprit.
It basically took me all night to get gcc 4.4.3 installed on this opensolaris server, but once I did, and recompiled php 5.2.12 + lsapi 5.2, it started serving PHP right away. I'll try the same approach on the production servers.
Maybe this is a good warning for a wiki? GCC 3.4.3 is the compiler issued with opensolaris (amazing, isn't it?), so this might be a problem that someone else runs into as well.
It basically took me all night to get gcc 4.4.3 installed on this opensolaris server, but once I did, and recompiled php 5.2.12 + lsapi 5.2, it started serving PHP right away. I'll try the same approach on the production servers.
Maybe this is a good warning for a wiki? GCC 3.4.3 is the compiler issued with opensolaris (amazing, isn't it?), so this might be a problem that someone else runs into as well.