Doe your Webserver allow more then 1 Apache child to be running at any one time?

Yes there are always between 5 and 10 childs waiting for connections.

I have a couple scripts that worked 100% of the time under PHP 4.2.3.  Immediately after the upgrade to PHP 4.3 I get the function.fsockopen: php_hostconnect errors as well.

Here are two of the links you can launch an "authorized" scan from to see the errors:

http://www.computercops.biz/modules.php?name=Trojan_TCP_Scan
http://www.computercops.biz/modules.php?name=TCP_Scanner

These pages make use of the same code as posted earlier in this bug report by support@hostcolor.com.

To reiterate, under PHP 4.2.3 this code worked perfectly fine.  Now PHP 4.3 has broken it and I cannot seem to fix it.

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

If you read the release notes, you will notice that 4.3.1 contains *NO* bug fixes.
Please try the stable snapshot as requested (which *DOES* contain bug fixes).

Ok, the problem wasn't resolved using php 4.3.x.  This is the response from my host admin:

<start quote>
I do not normally install snapshot builds, the latest releases are used. Released versions undergo a testing phase that a development tree do not have. This applies to most software. The snapshot installed now is marked as 4.3.2-RC, or release candidate, which means that "if we do not get too many bug reports for this version it will become a release." However, a PHP developer will undoubtably know more about PHP than I do. If they are suggesting the use of this version they must be comfortable enough for it to be used in a production environment. 

I am not sure what you are needing to know now, if a PHP contributor or developer recommends use of this version it should be fine. 

The upgrade was performed in the same manner all of your custom builds are installed: 
PHP is configured/built. 
PHP is installed into the apache source tree. 
Any other apache modules are installed at this time. 
Apache is built, including PHP as a static module. 
The new binary or binaries are copied to your system. 
Apache is restarted. 

The only difference between the upgrade and the usual install process for your httpd was that a different PHP source tree was used. 

</end quote>

My host has read this bug report and has seen your suggestion.  The response is as above.

Help?  Ideas? 

Thanks in advance.

I also am experiencing this issue after just updating php. 

Here are 2 links that are displaying the errors...

https://www.hostusa.biz/status.php
https://www.hostusa.biz/whois/index.php (do a whois lookup)

Any info on this would be appreciated.

This is now a problem for me as well. I am running PHP 4.2.3 under Linux. When I was using the built in MySQL libraries, this was not an issue. However, now that I've recompiled (same apache version, same PHP version) I am showing the same problem. Restarting Apache seems to correct it temporarily.

(Apache 1.3.27, Mysql 4.0.12, PHP 4.2.3)

Just putting in my two cents... suddenly SquirrelMail doesn't run because of this error.  Please get this bug fix in soon.  Thanks.

How long does it take to produce the error message?
You are specifying a timeout of 30 seconds; if it takes longer than 30 seconds, PHP will abort the connection attempt, even if it is "in progress".

Also, this item from the NEWS file is also relevant:
- Added php.ini option "default_socket_timeout" to set the
  timeout limit for PHP network streams.
 (kalowsky, ilia@prohost.org, Wez)

The default value is 60 seconds (it was introduced to avoid DoS attacks).

You can set this value from your scripts as well in the ini or httpd.conf. (see docs for ini_alter).

My issue still hasn't been resolved because we still haven't traveled down your recommended path.  Someone at my provider is looking into this for me.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

I am receiving the same issue with eNoms app. Worked in 4.2.3 now receive that error with 4.3.1.

Warning: fsockopen() [function.fsockopen]: php_hostconnect: connect failed in /home/xxxxxxxxx/include/EnomInterface_inc.php on line 140

Warning: fsockopen() [function.fsockopen]: unable to connect to resellertest.enom.com:80 in /home/xxxxxxxxx/include/EnomInterface_inc.php on line 140

Fatal error: Call to undefined function: strerror() in /home/xxxxxxxxx/include/EnomInterface_inc.php on line 142



Line 140+
		$address = gethostbyname( $host );
		
		// Create a TCP/IP socket.
		$socket = fsockopen($host,80); 
		if ( !$socket ) {
			$this->AddError( "socket() failed: " . strerror( $socket ) );

I experience the same problem with fsockopen. Is this ever going to be fixed? (I am using PHP 4.3.2)

My current host has not done this whatsoever, we have obtained another server with another host.  We'll be working on it this week.  On the new server we see the same exact error as on the current server at computercops.biz.  So the new server will have the CVS build installed.

Cross your fingers.  (crossing ours)

I just started seeing this bug in code that worked for PHP 4.1.2 (never saw this error for almost a year of daily use) when my ISP upgraded to 4.3.2.  I am using it in a pop mail reader.  I don't see this error every time I try to connect to the mail server, just randomly, although it tends to occur many times in a row if I reload the page.

The code looks like this: 

 $this->Socket = fsockopen($server, $port, $errno, $errstr, 5);
 socket_set_timeout($this->Socket, 5);

Where $port = 110 for a pop mail reader, and $server is the address of my mail server.

Originally the timeout was set to 30, but I read a post by another user who eliminated this problem by lowering their timeout.  That didn't work for me.  Whether the time out was 5 or 30 seconds, the error would return immediately.

Here's my ISP's system software versions: 

OS: RedHat 7.3
Apache: 1.3.27
Mysql: 3.23.56
Tomcat: 4.1.12
JDK: 1.4.1
PHP: 4.3.2
PERL: 5.6

Thanks for any help in a fix or workaround for this bug, which is affecting me daily.

We were running into this exact problem and it was driving us nuts....  but.... we noticed it happened after a kernel upgrade where ECN was enabled by default.

Try disabling it with:

echo 0 >/proc/sys/net/ipv4/tcp_ecn

... and see if the errors go away.

More info on ECN is here:   http://gtf.org/garzik/ecn/

-ken

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

For those of you using Linux, if the ECN suggestion does not work for you, please try the latest stable snapshot as it contains a linux specific workaround that *might* solve your problem.

If it does, report back here and we can make the workaround a more portable solution.

Hi folks, we finally have a new server, and we just now installed the CVS Stable build from your recommended download:

http://snaps.php.net/php4-STABLE-latest.tar.gz

You can see the phpinfo here:

http://64.246.34.44/phpinfo.php

And you can see the port scan page here, and the same exact errors show up in this STABLE CVS 4.3.3RC2-dev build that I downloaded via your recommended link.

So it appears, this is an actual bug as you can see other folks are running into the same issue.

What is the next step?  I'd like to help in debugging this issue such that it can be resolve sooner rather than later.

Thank you,

Paul Laudanski
http://64.246.34.44/testpaul.php

Oops, I did not mean to place the "testpaul.php" file at the end, however, here is the link again:

http://64.246.34.44/testpaul.php

Thank  you... don't mind the "test" in the file name, it contains the code exact code as found at computercops.biz I linked to way above.

Paul

When I visited your test page, it seemed to be working; the port-scans triggered my port-sentry and that dropped the route to your machine.
So the only "problem" is that you see two separate error messages?
I've removed a redundant message from the stable branch.

Yes that error message pops up.  If you run it with a couple of those open ports, what do you get?

But yes, I'm getting those errors.  Re-download newest stable?

Yes, get the latest stable snapshot..

HI, I grabbed the newest stable snapshot today (http://snaps.php.net/php4-STABLE-latest.tar.gz), build:

php4-STABLE-200306271330 / PHP Version 4.3.3RC2-dev

And the problem still shows up:

http://64.246.34.44/testpaul.php

Warning: fsockopen(): unable to connect to xxx.xxx.xxx.xxx in /var/www/html/testpaul.php on line 134

Which is this line in the script:

$fp = fsockopen($REMOTE_ADDR, $portno, $errno, $errstr, 1);

For confirmation of the build, you can use this:

http://64.246.34.44/phpinfo.php

Thanks

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

Sample script appears to work correctly, assuming fixed.

Hi, thanks for the reply.  I'll grab the newest stable source tomorrow morning and give it a try once more.  But as of my last comment above, the error message I get is:

Warning: fsockopen(): unable to connect to ...

Again, I'll test it out again tomorrow with the newest build and report back.

Thanks

Download: .bz2 (3.5M) .gz (4.3M) 
Built On: Jun 30, 2003 11:30 GMT
php4-STABLE-200306301130

http://64.246.34.44/phpinfo.php
http://64.246.34.44/testpaul.php

Hi, I grabbed the latest stable cvs snapshot and it appears the problem persists.  Its the same code, no change, since I started using it prior to PHP 4.2.3.  For some reason, it doesn't work with 4.3.x.

Now, for my UDP scanner (http://www.computercops.biz/modules.php?name=UDP_Scanner) on PHP 4.3.x I use the following code which works well with either 4.2.3 or 4.3.x:

$handle = fsockopen($this-> targetIP, $portNumber, &$errno, &$errstr, 2);

For the TCP Scanner (http://www.computercops.biz/modules.php?name=TCP_Scanner), I have this line:

$handle = fsockopen($this-> targetIP, $index, $errno, $errstr, $this-> timeout);

So something is different between the TCP and UDP connections.  Now, I'm running these scans from a box that is dropping the probes.  Hence, since UDP is connectionless and TCP is connection oriented, the bug may have something to do with this?  I haven't tested it on a system that is not running a firewall recently.  What do your tests show now with the current snapshot?

Thanks

(Phew, this is one elusive bug).

P.S.  Here is my configure statement:

./configure --with-mysql --with-apxs --with-gd --with-jpeg-dir=../jpeg-6b/ --with-zlib

CORRECTION TO THIS:

So something is different between the TCP and UDP connections.  Now, I'm
running these scans from a box that is dropping the probes.  Hence,
since UDP is connectionless and TCP is connection oriented, the bug may
have something to do with this?  I haven't tested it on a system that is
not running a firewall recently.  What do your tests show now with the
current snapshot?

------------

CORRECTED VERSION:

*... Now, I'm running these scans from the server against a system that is dropping the probes via a firewall.  ... I haven't tested it on a system that is not protected by a firewall (or disabled it).  What do your tests show now with the current snapshot? ...*

-----

Thanks

Ok, I disabled any port blocking on my end this morning, and as it turns out I get the same messages as when port blocking was on:

Warning: fsockopen(): unable to connect to xxx.xxx.xxx.xxx:21 in /var/www/html/testpaul.php on line 134
Connection Refused: Port 21 used by Nerte 7.8.1.

This is odd indeed.

HI folks, welcome back.  So, what is the status?  Those errors are still there.

I am not the original submitter of the bug but I was contacted by mr. Paul Laudanski and also by seeing the number of comments it seems that the problem is still there. We certainly found no solution as nothing else but reverting to 4.2.3 helped.
best regards and good luck

This is propably stupid question..but why shouldn't fsockopen() give an error when it fails to connect???
Obviously that's what is happening here? :)

Each "ports are filtered or open" line is with respect to the client PC (target PC), and not the server that PHP is installed.

Scenario A: 

- ports are filtered (closed or stealth)
- PHP 4.2.3 is installed

Scenario B:

- ports are open
- PHP 4.2.3 is installed

Scenario C:

- ports are filtered (closed or stealth)
- PHP 4.3.x is installed

Scenario D:

- ports are open
- PHP 4.3.x is installed

Ok, under both Scenario A and B, no "fsockopen()..." error is generated.

Under both Scenario C and D, the "fsockopen()..." error is displayed.

Clearly what worked 100% of the time in 4.2.3, no longer functions in 4.3.x.  This has been an ongoing issue for several months now.

In addition, the http://64.246.34.44/ address I listed just above is no longer in use.  You can refer back to the original http://computercops.biz links way above.

Thanks

In addition, I'm not sure why the error would continue even after wez...

"[22 Jun 5:11am CDT] wez@php.net 
When I visited your test page, it seemed to be working; the port-scans
triggered my port-sentry and that dropped the route to your machine.
So the only "problem" is that you see two separate error messages?
I've removed a redundant message from the stable branch.

"

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

No feedback from original bug submitter.
laudanp at yahoo dot com:
If you still feel this is a bug, open new report with
short example script, expected result and got result.

Hi I provided the feedback above, I'm still having those problems.  Help

re: "No feedback from original bug submitter.
laudanp at yahoo dot com:
If you still feel this is a bug, open new report with
short example script, expected result and got result."

Thanks for replying to me.  I'll go ahead and open a new ticket while referencing this one for posterity.  Look for it tonight.

I opened a new bug report here:

http://bugs.php.net/bug.php?id=24785

Hi,

I get the following error:

Warning: fsockopen(): unable to connect to whois.crsnic.net:43 in /home/ecompco/public_html/test.php on line 2
Could not open connection

However, the connection is made perfectly and fast when I switch off APF. I get:

Connected OK.

For the life of me I cannot figure out why - I've added ports 43, 443, 4343, 80 to conf.php but still error shows when APF is on. But it does have something to do with APF.

Regards,
Suhail.

I have a similar problem using php 4.4.1 with pfsockopen
Part of code:
------------------
<?php
$fp = pfsockopen("ssl://example.com", 443, $errno, $errstr);
if (!$fp){
    echo "$errstr ($errno)<br>\n";
    exit;
}
?>
Output:
------------------
Operation now in progress (115)

Modules:
------------------
'./configure' '--with-gd' '--with-msql=/usr/local/msql2.0' '--with-mysql=/usr/local/mysql' '--with-apache=../apache_1.3.34' '--with-jpeg-dir=/usr/lib' '--with-png-dir=/usr/lib' '--with-mhash' '--with-openssl=/usr/local/ssl' '--enable-ftp' '--enable-imap' '--with-zlib-dir=/usr/local/lib' '--with-pear' '--with-curl=/usr/local/lib' '--with-pear=../PEAR-1.1' '--enable-mbstring=all' '--with-dom=/usr/local' '--with-domxml=/usr/local' '--enable-memory-limit=yes' '--enable-sockets' '--with-gd-native-ttf' '--enable-gd-imgstrttf' '--with-freetype-dir=/usr/local' '--enable-shared' '--with-expat-dir=/usr/local' '--with-dom-xslt=/usr/local' '--with-xslt-sablot'

Additional info
--------------------
I have it working on another domain and server with php 4.3.4

I'm getting the same "Operation now in progress (115)" w/ PHP  4.4.2 configured with:	 

'./configure' '--with-mysql=/usr' '--with-apxs2=/usr/local/bin/apxs' '--enable-mbstring'

and using Apache 2.0.59 on RHEL 4 and using this script:

<?php
$fp = fsockopen ("localhost", 80, $errno, $errstr, 30);
if (!$fp) {
    echo "$errstr ($errno)<br>\n";
}
fclose ($fp);
?>

What I have been able to figure out is that if I have less that ~500 virtual domains in the httpd.conf file, the problem goes away.  If I have more, the problem comes back.  Am I hitting some kind of resource limit?

I have the same problem with Mac OS X 10.4.8 and PHP 5.2.
Unix sockets on the same machine work OK. Same code with TCP/IP socket fails with "Operation now in progress".