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.
Related
My code is fairly simple. I'm using the library over at https://github.com/stomp-php/stomp-php, and try to read messages from an Artemis queue. It's just a simple $stomp->read();.
Expected behaviour:
I get one message from the queue, or get told that there are no messages in the queue
What is happening:
The read method throws an exception (see below)
When we don't connect using SSL, with a basic TCP connection, without a certificate, everything works perfectly fine. It happens only when we connect with the ssl scheme, the SSL port, with the certificate.
The exception is: Was not possible to read data from stream., thrown in [stomp-php directory]/src/Network/Connection.php line 473.
Here is the context for the stream connection:
ssl:
peer_name: '[censored]'
cafile: '[censored certificate path].cer'
The certificate file exists and is read correctly (since when I change the path there's an exception thrown even before trying to send a message). The peer name is also correct, since another one triggers another error telling me that the peer name is incorrect.
My test is simple: I have a file that sends the messages, and a file that reads them. The sending always works when I don't subscribe to the queue. The reading is kinda messy.
New information: the reading seems to work when I remove 5 specific messages from the sending. That means if I send one of those 5, the reading throws the exception. If there are only the other messages but none of these 5, the reading works great. I would assume that the messages are in cause, but again, when I'm not connecting using SSL, everything works correctly.
New information again: every message that I have to not send in order to not have an error has a big amount of lines. I tried to send one of them again and remove every node but one from its content (XML): it worked correctly. So I tried with ~900 nodes: error. ~200 nodes: error. ~130 nodes: sometimes error. ~80 nodes: working.
SSL has troubles with large messages?
New information again again: I tried var_dumping the result of the fread call in the library. When the error occurs, the result is an empty string (''). From what I read in the doc, fread returns false on failure, and empty string on timeout. It would make sense with the "New information again" bloc, in which we discovered that large messages are causing the problem.
I tried stream_set_timeout() with 60 seconds, I tried to send a heartbeat manually, I tried setting it with the lib, I tried changing the timeouts with the lib and I tried increasing the maxReadBytes. Nothing worked so far. Still the same behaviour.
Fixed by reverting stomp-php library to version 4.3.1 :(
i have a problem with the "Paypal PHP Restful SDK". My yproblem is, that (in sandbox mode) i get sometimes the error "Could not resolve host ...". This happens about every 10'th payment session in sandbox-mode.
Here the logged error:
mod_fcgid: stderr: PHP Fatal error: Uncaught exception 'PayPal\\Exception\\PayPalConnectionException' with message 'Could not resolve host: api.sandbox.paypal.com' in /var/www/xxxxx.com/httpdocs/app/paypal/paypal/rest-api-sdk-php/lib/PayPal/Core/PayPalHttpConnection.php:137
the corrospending line from the SDK is:
//Throw Exception if Retries and Certificates doenst work
if (curl_errno($ch)) {
$ex = new PayPalConnectionException(
$this->httpConfig->getUrl(),
curl_error($ch),
curl_errno($ch)
);
curl_close($ch);
throw $ex;
}
Info: I have no Certificate on my vServer
Does somebody know, what is working wrong?
There's insufficient information to fully diagnose the problem and find the the culprit. You can have i.e. networking problem on your run environment, DNS setup problem, connection timeouts etc etc. Yet as the issue occurs frequent enough to reproduce it you may try to resolve api.sandbox.paypal.com using other tools like host or dig, or you can even craft PHP script that would simply do:
error_reporting(E_ALL);
var_dump(gethostbyname('api.sandbox.paypal.com'));
and run it many times to see if the problem would occur here too. If it does, then I am afraid SO is not the right place to continue chasing this type of issues but as workaround/temporary fix you could either use IP (currently 173.0.82.78) address instead of api.sandbox.paypal.com or edit your local /etc/hosts file and add
173.0.82.78 api.sandbox.paypal.com
You can always try flushing your DNS cache, restarting the network interface.
You can also try pinging and check if PayPal API is indeed pingable(reachable), try changing to Google DNS too, maybe that'll sort the issue.
I'm trying to append a hush database directly from php.
$mysqli->query(file_get_contents('huge.sql'));
but I'm getting :
Warning: mysqli::query(): MySQL server has gone away in
I was add those 2 line at the beginning of my php code :
ini_set('mysql.connect_timeout',3000);
ini_set('default_socket_timeout',3000);
Not very helpful...
Unless you're getting an actual error and not a Warning, this doesn't necessarily mean you're doing something wrong.
With PDO for example, this warning can be issued when pooled connections are in use, such as when PHP is running as an Apache Module. There is a similar post here: How to fix the "server has gone away" warning when mysqli reconnects a persistent connection?
If what you're getting is simply a warning, and the query runs fine anyway, then you can either choose to request a persistent mysql connection, or ignore and suppress the warning.
If you're getting an error and your connection is getting terminated, then you should see https://dev.mysql.com/doc/refman/8.0/en/gone-away.html for most common causes of this issue.
I have a codeigniter app on google app engine and as I move about the application it will mostly work but I'll get these intermittent problems where I'll click on a page and it'll be completely blank with only a title in the HTML that reads:
<html><head>
<title>s~nypl-cap : uncaught application failure</title><body><pre><br></pre></body></html>
When I check the logs all I get is a 500 error that reads:
"A problem was encountered with the process that handled this request, causing it to exit. This is likely to cause a new process to be used for the next request to your application. (Error code 204)"
If I refresh the page it reloads just fine. I have no clue what could be wrong any help would be appreciated.
"App Engine cannot have more than 12 concurrent connections to a Cloud SQL instance". So, you need to close the any established connections before processing a request. If you do not do this it will cause a leak may eventually new connection to fail. And that could be one of the reason why you are getting 204 error. So in your "database.php" file in Production (App Engine Cloud SQL) DB Settings section can you change the line $db['production']['pconnect'] = TRUE; to $db['production']['pconnect'] = FALSE; and see if it works or not.
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.