How to catch fsockopen() time out

PHP Warning: fsockopen() [function.fsockopen]: unable to connect to xx.xx.xx.xx:3306 (Connection timed out) in /home/...

I’m trying to catch or silence an error message when the fsockopen() function times out. In the code below I’ve added my trigger_error() function which in other cases does my error reporting but with fsockopen() I get both the php warning plus my custom error message

$fp = @fsockopen($serverinfo["ip"], $serviceinfo["port"], &$errno, &$errstr, 4);
if (!$fp)
{    trigger_error("Socket error", E_USER_ERROR);

The error log shows

56: the warning issued by php
57: my trigger_error() message
58: This is interesting! fsockopen() seems to have destroyed the $_SERVER array, at least the $_SERVER[‘SERVER_NAME’] cell!

56 [13-Feb-2013 15:40:05] PHP Warning: fsockopen() [function.fsockopen]: unable to connect to xx.xx.xx.xx:26 (Connection timed out) in /home/.../upstat.php on line 66

57 [13-Feb-2013 15:40:05] PHP Fatal error: Socket error in /home/.../upstat.php on line 68

58 [13-Feb-2013 15:40:05] PHP Notice: Undefined index: SERVER_NAME in /home/.../phpErrorReporter.php on line 213 

The fsockopen() timeout warning is really cluttering up my error log and I’d like to suppress it. Can it be done? Note the “@” is already in place.


Did this question stump all the SitePointPros? :cool:

You could wrap your code in a try {} catch statement which should prevent anything coming up in your error_log file.

Thanks. Interesting idea but it didn’t work. I’ve been giving this problem a lot of thought and my conclusion is that fsockopen() can give two errors, one when you call the function and a second one when it times out which could be several seconds later. My best guess is that php is designed to catch only one error per instruction or per function and not the second error that happens later and which is an error of the outside world that didn’t send the data as expected.

The try/catch approach wouldn’t suppress the warning, it could suppress errors, but not warnings (think about it, it just doesn’t make sense for a try/catch to capture a warning).

The @ was specifically designed to suppress warnings and errors, but what I don’t know is if it was designed to suppress them from being displayed on screen, to suppress them from being logged, or both.

Considering the fact that even with using warning/error suppression that the warning is still logged, tells me two things. 1) You found a bug, or 2) The warning/error suppression was never designed to stop them from being logged (if your logging level is setup to capture both warnings and errors).

To my knowledge there isn’t any other way to approach this problem. You could file a bug report with PHP, but make sure you go into very detailed specifics and make sure you are using the latest version (to make sure it isn’t a bug in yours).

As far as I know the @ will make the warning “silent” meaning it won’t be reported. As to where it is not reported depends on you error display settings (screen, log, either, neither).

I think the “bug” is that fsockopen() can fail in two different ways, when called – which is handled the usual way – or later when the connection times out. It’s this later time-out that’s causing my problems. I’ve been thinking about submitting a bug report, not something done lightly.

Do you know which timeout you are hitting? The connection or interacting with the stream?

The manual states you may need to use stream_set_timeout() in conjunction with the timeout parameter of fsockopen. Granted neither of these approaches provide a way for you to suppress the message beyond what you’ve already provided in your code.

Connection time-out.