ID: 25195 User updated by: mhawkins at ukeu dot com Reported By: mhawkins at ukeu dot com -Status: Feedback +Status: Closed Bug Type: Mail related Operating System: Solaris 8 PHP Version: 4.3.3 New Comment:
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. Previous Comments: ------------------------------------------------------------------------ [2003-11-03 18:50:23] [EMAIL PROTECTED] 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? ------------------------------------------------------------------------ [2003-08-27 18:37:19] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. On *nix systems when sending e-mail PHP uses popen() to open a pipe to the sendmail binary. In your case that appears to fail, as far as my man page can tell this can only happen if you are out of memory or reached the maximum process limit causing fork()/pipe() to fail. As such this is not a PHP issue. ------------------------------------------------------------------------ [2003-08-21 11:08:26] mhawkins at ukeu dot com Description: ------------ Solaris 8 on Sparc SunONE Webserver 6.0sp5 (AKA iplanet) PHP 4.3.3RC2 (yes, I know, I should upgrade to RC4 first, but this is a production system) Sendmail - default as per Solaris 8. Error: PHP Warning: mail(): Could not execute mail delivery program in /opt/sunone/es/docs/download.php on line 174 php.ini: sendmail_path = "/usr/lib/sendmail -t -i" config.status: ./configure --prefix=/usr/local/php --with-mysql=/usr/local/mysql --with-nsapi=/opt/sunone/es --enable-track-vars --enable-libgcc The code works perfectly for a few hours, sending mails as expected, then the above error appears, and continues to fail until another webserver restart is performed. Prior to the sendmail_path variable being set, the error would log to /var/adm/messages, but since the change it only logs to the webserver errorlog. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=25195&edit=1
