I've seen this error a couple of times, and to fix it, I just reboot my server.
Fatal error: Uncaught exception 'MongoConnectionException' with
message 'Failed to connect to: localhost:27017: Previous connection
attempts failed, server blacklisted' in
/var/www/html/include/config.php:9 Stack trace: #0
/var/www/html/include/config.php(9):
MongoClient->__construct('mongodb://local...') #1
/var/www/html/classes.php(3): include('/var/www/html/i...') #2
/var/www/html/myusers.php(8): include('/var/www/html/c...') #3 {main}
thrown in /var/www/html/include/config.php on line 9
However, I can be a while without seeing it... How can I prevent the issue from happening?
update: it happened again and after several minutes of waiting, I had to reboot to make the site work again
Since the 1.4 versions of the MongoDB driver for PHP we will "blacklist" servers for up to a minute if they can not be contacted to. This is so that we do not slam the server with connections, that might timeout. This is primarily done to make sure that in a replica set environment we can still proceed by just using another of the hosts, but of course if you only have one machine, this is a bit trickier.
If you use MongoLog then you can very easily spot what happens under the hood:
MongoLog::setModule(MongoLog::ALL);
MongoLog::setLevel(MongoLog::ALL);
MongoLog::setCallback('print_mongo_log');
function print_mongo_log($a, $b, $c) { echo $c, "\n"; }
This will display everything the driver is trying to do. It would be interesting to see the first dump of when something goes wrong, and also for one time it is "stuck" on the blacklist.
The above warning will go away after 60 seconds, or upon reboot of your web server software (or PHP-FPM is you use that). If you think this explanation is not correct, please file a bug/feature request at http://jira.mongodb.org/browse/PHP
Apparently, this is an issue caused by a bug in MongoDB's PHP driver. Check if you're using version 1.4.0, if yes, update to a newer version and the error should be fixed.
It seem mongo handle connections itself, you should not use close connection in your code if you want use persistence mongo connection, I've resolved this issue by removing close from mongo connection php script like this:
DON'T USE CLOSE..............
$client = new MongoClient("mongodb://127.0.0.1:27017");
//close mongo connection
$client->close();
Hope to be useful.
Related
Have a docker container build using php-ssh2. php version 7.2 When trying to use
$con = ssh2_connect('hostname');
I am getting Error starting up SSH connection(-43): Failed getting banner . Interesting thing is 43 here. Whats the significance of 43. What does that mean? Also any idea how to fix this? There is no heavy load, running connection manually.
Deepdive into libssh2
This number -43 is an error code that comes directly from libssh2, specifically LIBSSH2_ERROR_SOCKET_RECV. The Failed getting banner message is the dynamic error message that accompanies the error code. These two pieces of information give the location where this error is thrown, namely in the receive_banner.
Underlying problem
It was the result of the socket throwing a receive error when libssh2 tried to read from it as part of initialising your SSH session. Either the server is misconfigured and is not sending a banner or the underlying connection disconnected for some reason.
Solution
The best course of action seems to have adequate retrying in place for these kinds of errors. You are connecting to a network which is an action that can fail. As the number of servers you are connecting to increases, you are going to run into errors that are a result of the underlying network. Adequate error handling is your best course of action.
You can find how to set exception handlers from the PHP docs.
A PHP software I wrote has been working fine for years suddenly throws this error: i360: Error in global initialization
This error is being thrown from the callback function register_shutdown_function('my_shutdown');
The callback function is just something this:
function my_shutdown ()
{
chdir(getcwd());
$e = error_get_last();
if ($e)
trigger_error($e['message'].' on '.$e['file'].' ('.$e['line'].')', E_USER_ERROR);
}
The full error message that trigger_error throws is:
i360: Error in global initialization 1 on Unknown (0).
It doesn't give much clue. Any ideas what could be causing it?
Update 1:
If I comment out the entire my_shutdown() function, the script works fine but I am still intrigue as to why this error happened just today after years of working fine.
Update 2:
Tentative info: this appears to be related to Imunify360, a security software for web servers (which my host uses that I'm not aware of or have control over). Investigation ongoing.
This issue is caused by Imunify360 because of a recent update to include a feature called "Proactive Defense":
https://www.imunify360.com/blog/meet-imunify360-with-proactive-defense-the-sophisticated-protection-against-any-kind-of-malware-all-in-one-nice-package
To fix this you need to have your host disable the extension over all PHP versions:
sed -i "s/extension=i360.so/;extension=i360.so/g" /opt/alt/php*/etc/php.ini
That should fix the problem for the time being.
This error happened just today. It disappears when I delete my cron jobs on Hawk Host cpanel.
This error was confirmed to be coming from Imunify360 (a security software for web servers). At the time of this writing, the issue was already fixed on their end. I presume an update was applied to servers using it so if you're still getting this error, contact your host.
Very simple-to-explain problem here (at least after struggling with it and simplifying it almost up to the absurd).
I do a connection via the OCI driver inside a file called whatever.Test.php. Just that, make a simple query, and exit. I then call the file from the browser, and the data taken from the database is properly displayed. Next step: I run PHPUnit over the same file, with the following result:
PHP Warning: oci_connect(): ORA-12154: TNS:could not resolve the connect identifier specified in ...
Any ideas?
The final solution was a little bit obvious once I came up with it. Somehow the server could figure out what the server I was trying to connect with was, via the tnsnames.ora file somewhere, I guess. However, since the script execution doesn't trigger all the server processes this information was not reachable any more from there. So what I needed to do is to provide all the data in the oci_connect() $connection_string parameter, using the format [//]host_name[:port][/service_name][:server_type][/instance_name] (check documentation). Previously I was only giving the host_name part.
(Thanks anyway for your reply, user*).
I started getting this error when trying to query the database on a connection that had timed out.
Fatal error: Uncaught exception 'ErrorException' with message 'mysql_query(): MySQL server has gone away'
So I did a bunch of research and 99% of the users on the forum say you can use the mysql_ping command to check for a connection, so I put this in place:
if(!mysql_ping($this->sDBLink))
Connect(true);
Now I get the same error, just in reference to the mysql_ping function instead of the mysql_query function:
Fatal error: Uncaught exception 'ErrorException' with message 'mysql_ping(): MySQL server has gone away'
How do I reliably check that a connection still exists? mysql_ping throws an exception.
Why does a connection time out? Because it has been unused for a period of time longer than a particular threshold. This kind of thing is necessary for all kinds of network applications to make them resilient. What if a user abruptly switches off a client machine while it is connected to a MySQL server? The server needs to be able to drop the client connection after a while.
This kind of thing is inherent in network programming. It's a feature, not a bug.
What can you do about this?
You can switch to a more modern mysql connection management library that handles this stuff.
Especially if your client software gets used infrequently, you can reorganize your software to connect to MySQL, use the connection, and disconnect. That way you won't need a persistent connection. But that's impractical if your client server gets used a lot; there's a lot of overhead to establishing a connection.
You can change the timeout value. See here. how to change timeout for mysql persistent connections
You can use the connection regularly. mysql_ping uses the connection without actually doing any server work. So would a query that said something like SELECT 1. If you ping the connection every minute or so, then a two minute timeout won't cause your MySQL server to conclude that your client has gone away and disconnect it.
You can handle the ErrorException you're getting correctly, by trying to re-establish the connection instead of just blowing out your program with an error message. Use PHP code something like this:
try {
some operation on the mysql connection.
}
catch (ErrorException $ex) {
disconnect mysql
connect mysql
}
So I know this is ugly and makes me sick it, but it will work until we can get enough income to warrant an upgrade.
All I did was close the connection then recreate it as I know the connection will have timed out almost 95% of the time.
if($this->sDBLink){
mysql_close($this->sDBLink);
}
if($bPersistant){
$this->sDBLink = mysql_pconnect($this->sHostname, $this->sUsername, $this->sPassword);
} else {
$this->sDBLink = mysql_connect($this->sHostname, $this->sUsername, $this->sPassword);
}
I've been migrating a website from one server to another. The code is massive, so naturally I've had my share of problems. I believe they're all solved except for this persistent one:
On a particular page, I get the following error:
Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: fetch mode requires the colno argument' in /home/username/public_html/admin/lib/database.inc.php:59
The line referenced:
$myResult->setFetchMode(PDO::FETCH_COLUMN);
I've been back and forth through the PDO documentation, so my diagnosis was originally that setting the fetch mode to PDO::FETCH_COLUMN required also setting a column number - no great deduction there. So I tried a value of 0 as the second argument. The page spent more than 30 seconds loading and got a PHP timeout. Same for a value of 1, and then I decided this wasn't the path to success.
Now, the really perplexing thing is that this site works perfectly on my local test machine without any modification, as well as on the original production server. I don't have easy access to the specs on the old server, but I know that those of my local test machine match those of the new server pretty damn closely.
Specifically:
Local PHP: 5.3.3
Remote PHP: 5.3.4
Local MySQL: 5.1.37
Remote MySQL: 5.0.91
Since I know the code is good with some configuration, I'm hoping someone knows the magic switch I can flip.
--EDIT--
Even with error_reporting set to E_ALL | E_STRICT on the local machine, this PDO exception doesn't appear.
Solved. Don't ask me why, but downgrading PHP to a particular version - as recommended by the original devs - did the trick. Nevermind that it was working fine locally with a more recent version. It just worked.
Old question I know, but I was getting the same error and thought I'd post what I found. I solved it by using prepared statements and passing PDO::FETCH_COLUMN to fetchAll().
$query = $database->prepare($sql);
$query->execute();
$result = $query->fetchAll(PDO::FETCH_COLUMN);
I don't know why it works that and not with $database->query(). I don't need prepared statements here because I am not passing any parameters to the SQL, but it works so I roll with it. Hopefully that helps someone else who has this same error.