ID: 25195
Updated by: [EMAIL PROTECTED]
Reported By: mhawkins at ukeu dot com
Status: Closed
Bug Type: Mail related
Operating System: Solaris 8
PHP Version: 4.3.3
New Comment:
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\"").
Previous Comments:
------------------------------------------------------------------------
[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] [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.
------------------------------------------------------------------------
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
http://bugs.php.net/25195
--
Edit this bug report at http://bugs.php.net/?id=25195&edit=1
