Search results

NiteWave, If that setup means Litespeed launches a new instance of PHP for each page serve and then it terminates, it means you would not detect the issue. Assume the setup was on Solaris 10 and assuming the php script exited early using the exit procedure, PHP would leak one file descriptor...

Hi Nitewave, Actually, I wrote that on the bug report, so I'd be quoting myself. How fast the error comes up depends on the number of pages served and if and when they use the "exit ()" function. The default limit on file descriptors is 256 on Solaris, so it doesn't take too long to hit the...

I've finally tracked this file descriptor leakage problem down. It is a bug in PHP that has existed since 5.2.9, as described in this bug report: http://bugs.php.net/bug.php?id=47675 It specifically affects Solaris 10. Recent versions of opensolaris don't have the same problem. If you...

The problem with the theory is two-fold: 1) When I drop back down to 5.2.8, I don't change the APC. It's the same accelerator for both versions, yet I only see the file descriptor issue on 5.2.12 2) 3.0.19 is the latest in the stable branch. A known problem would have posted (I would think)...

Okay, thanks. I may use LSAPI with Ada. If I am able to do so cleanly, I'll publish the code and maybe some documentation. No promises, and it's not immediately on my list of things to do.

FYI, here is the top stub of the PHP INFO function slayton-root# ./lsphp5212B -i | more phpinfo() PHP Version => 5.2.12 System => SunOS slayton 5.10 Generic_118855-33 i86pc Build Date => Feb 12 2010 13:12:55 Configure Command => './configure' '--prefix=/opt/csw' '--with-layout=GNU'...

I can't seem to solve this php 5.2.12 problem. PHP 5.2.12 is built from scratch using litespeed LSAPI 5.3 (but the same thing happens with 5.2 and 4.10), gcc 4.4.3. I am also running APC 3.0.19. After about 12 hours, I get variations of this message on the server: Warning...

Nitewave, I have recompiled php 5.2.12 with litespeed LSAPI V5.3, and it appears the segfault issue has been resolved. I had another issue with 5.2.12 crashing after many hours (too many files open error), but I degraded to autoconf 2.13 and upgraded bison and hopefully my php woes will...

By the way, had this already been published, maybe somebody would have created and shared the python and mono LSAPI interfaces by now. Per your own reference: http://www.litespeedtech.com/support/forum/showthread.php?t=1883 That was 12 releases ago, right? Document the interface, and maybe...

yeah, I knew I could dig around the php-lsapi code. I think there "is not much interest" because it has never been published and documented. If somebody spent the time to properly document the API, then people would consider using it. Given the benchmarks that nitewave just linked to, why...

you misunderstood the question. You publish PHP-LSAPI and Ruby-LSAPI. We all know that. However, you guys said that you would publish the API for LSAPI so that we could use it for our own applications. E.g. for things other than PHP and Ruby. This was mentioned long ago as a goal. I see no...

You misunderstood. V5.2 works fine with LSWS 3.3.23. It crashes when PHP is used for command line applications by crontab. It would crash the same if LSWS wasn't even running.

I seem to recall that the original intent for LSAPI is that it would be an alternative to the fastcgi protocol. How is this effort going? Will LSAPI be documented and available for use for our own executable programs? It seem this has stalled and that's a shame, I'm sure people are...

Follow up: I rebuilt php 5.2.12 with LSAPI 5.2 using GCC 4.4.3 on solaris 10 and openSolaris Nevada 130 and used it with LSWS 3.3.23. It works fine with LSWS, but it still segfaults and core dumps with my CLI scripts as mentioned before. This does not happen with LSAPI 4.10. So LSAPI 5.2...

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

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

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

Hi Mistwang, I tried "Truss" on opensolaris with -f child follow option. This output doesn't tell me anything, how about you? It was polling the spawned process fine until I started LSWS and tried to access a php page.

I absolutely agree. With FreeBSD 8 for a few months already, Litespeed should be updated. Is it really that difficult? What's the real issue here?

Chalk me up with the people with problems with LSAPI 5.1. I recompiled PHP 5.2.8 (a version that has worked well with LSAPI 4.8) on my 3.3.23 LSWS (solaris 10). phpinfo shows fine, but all of a sudden I started receiving cron job output -- core dumps on lsphp due to segfaults. These are...