Bug #25195 [Com]: Failed opening phpinfo.php ... in Unknown on line 0

Edit report at https://bugs.php.net/bug.php?id=25195&edit=1 ID: 25195 Comment by: lildurk25195 at gmail dot com Reported by: mhawkins at ukeu dot com Summary: Failed opening phpinfo.php ... in Unknown on line 0 Status: Closed Type: Bug Package: Mail related Operating System: Solaris 8 PHP Version: 4.3.3 Block user comment: N Private report: N New Comment: Lil Durk is a private agency dedicated to providing responsible access to legal cannabis for adults aged 19 and older. We’re an exclusively online retailer and wholesaler for recreational cannabis and a trusted source for information about cannabis and cannabis-related issues. We believe our work is meaningful and we take pride in our mandate to promote the socially responsible use of legal cannabis. https://lildurk.com/ Previous Comments: ------------------------------------------------------------------------ [2004-06-12 22:33:11] thetaphi@php.net This problem is well known and a problem of Solaris in all versions. For PHP 4.3.4 we ported a lot of code from PHP5 back to eliminate fopen(),... Scripts now start without any problems (until PHP 4.3.3 even this could fail). But there are still a lot of extensions that use stdio functions. A solution would be to write a temporary file with the complete mail (headers and text) and then execute: exec("/bin/sh -c \"/usr/lib/sendmail -t </tmp/mail.txt\""). ------------------------------------------------------------------------ [2003-11-21 16:56:50] jusdoit442 at yahoo dot com I have encountered the same problem and can verify the mail() function will work until the ns-httpd process has 255 or more file handles open. Then failure. We are using Solaris 8, iPlanet 6.0SP4, PHP 4.3.2RC2. './configure' '--enable-wddx' '--enable-sockets' '--with-mysql' '--with-gd' '--with-zlib' '--with-nsapi=/opt/iPlanet6.0SP4' '--with-jpeg-dir=/usr/local/bin' '--with-png-dir=/usr/local/include' '--with-freetype-dir=/usr/local/bin' And 'safe-mode' is off. I perceive the comment about 'modern' operating systems to say that the problem exists within the Solaris O/S and not within the PHP code using a facility with limited capabilities. Which means to say, is there not an alternate method to pass information to the 'sendmail' binary which would not terminate if more than 255 files were in use by the calling process? Please advise if there is ANY potential for a solution by modification of the PHP code. regards...ec13 ------------------------------------------------------------------------ [2003-11-04 05:12:21] mhawkins at ukeu dot com Hmm... Sun didn't suggest a Solaris patch for the issue, and so I doubt there's one in existance (yet). We're currently building a new server environment based on Solaris 9 instead of 8, so it'll be interesting to see if we can replicate the problem on the latest SunOS or not. I'll update this ticket when there's any further information, but if there's nothing that can be done at the PHP end for now, I'll close the ticket. ------------------------------------------------------------------------ [2003-11-03 18:50:23] sniper@php.net It works fine with modern operating systems, perhaps the kind people at Sun could come up with some patch? ------------------------------------------------------------------------ [2003-11-03 09:27:34] mhawkins at ukeu dot com After raising this issue with Sun, and having numerous engineers investigate the problem, the root cause has been traced back to the following (to quote their response): "In a blinding moment of clarity I believe I know what is causing the problems between iPlanet Web Server and PHP. Looking at the PHP source code I can see that sendmail is being invoked by the popen() function. This uses the standard I/O library (stdio) to communicate over a stream and pass information to sendmail. By choosing a stdio function the programmers have limited themselves to a maximum of 255 file descriptors. If you look at the stdio(3C) man page you can see this is clearly documented: The integer constant FOPEN_MAX specifies the minimum number of files that the implementation guarantees can be open simultaneously. Note that no more than 255 files may be opened using fopen(), and only file descriptors 0 through 255 can be used in a stream. In the truss you have supplied it's possible to see that popen is asking for and getting a couple of file descriptors, which are over this 255 limit: 2654/12: 14.7296 pipe() = 262 [263] 2654/12: 14.7301 close(263) = 0 2654/12: 14.7304 close(262) = 0 . . . 2654/12: 26.8940 pipe() = 265 [266] 2654/12: 26.8944 close(266) = 0 2654/12: 26.8947 close(265) = 0 The reason why this is failing is that the iPlanet Web Server has increased the soft file descriptor limit to 1024, thus allowing fd numbers > 255. Unfortunately this behaviour is detramental to popen() and breaks functions that depend upon the stdio library. Now then you won't see the problem initially as calls to popen() will return a file descriptor < 255, however over time as file descriptors are used up and processes hold open file descriptors you'll start to creap up to this 255 limit and that's when things will break." Their suggestions to resolve this were as follows: "I do have one workaround but the "cure" could be worse than the symptoms. I was talking with the iPlanet/SunONE folks about this yesterday. One of the main reasons that the Web Server increases the file descriptor limit is to allow more sockets to be created. By restricting the file descriptor limit to 256 you are seriously hampering the number of clients that can connect and will artificially limit the web server as it reaches 256 file descriptors and then stops serving pages, until a free descriptor becomes available. It's a difficult one to call but ultimately I believe PHP are at fault for using a programming method that is well known to have limitations on the number of file descriptors it can open. Seeing as this is supposed to be run within the confines of the web server it should not assume that there will only be 256 file descriptors available to it. The authors of PHP need to rewrite their code to work around this 256 fd limit." Any suggestions? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=25195 -- Edit this bug report at https://bugs.php.net/bug.php?id=25195&edit=1