ElasticSearch PHP client v2.0 keeps throwing “No alive nodes found in your cluster”


(Vladimir) #1

The elasticSearch runs fine on my centos as a non-service. I run it as
"sh bin/elasticsearch". The client I installed using composer is PHP
v2.0. It just won't do anything it used to do before. I used this before
and I could search, index documents, make index. Right now I cannot do
anything because of this error. The strangest thing is that
ElasticSearch seems to be running fine, and I can also call it with curl
like:

curl localhost:9200

Please advise on the PHP API failure? I tried:

  1. Opening port 9200 on my centos 6 for all

  2. Used every method from the book in PHP API: search, index, delete
    index, etc...always get the sme result this exception is thrown in the
    Elasticsearch/Client class

  3. Changed the owner of the directory nodes to centos, apache, elasticsearch - no use.


(Zachary Tong) #2

Good timing, I just wrote about this yesterday: “No alive nodes found in your cluster” message when using HTTPS endpoint in PHP API

If I had to guess, I'd say it's either SELinux policies or SSL. Run through that list I posted and see if any of them apply.

If not, can you post your code (particularly the config of the client) and I can take a look?


(Vladimir) #3

I am assuming this is what installing it is doing: I got the certificate and now I point to it. This is the config and calling the delete action which throws the "...no alive nodes..." exception:

require 'autoload.php'; //to call the cert installer autoloader

$hosts = ['https://localhost:9200'];
$caBundle = \Kdyby\CurlCaBundle\CertificateHelper::getCaInfoFile();

print "

"; print_r($caBundle); print "
";

require '../vendor/autoload.php'; //call the PHP ElasticSearch API vendor autoload

$client = Elasticsearch\ClientBuilder::create()
->setHosts($hosts)
->setSSLVerification($caBundle)
->build();

print "client var is:

"; print_r($client); print "
";

try {
$client -> indices() -> delete(array('index' => 'er'));
} catch (Exception $e) {
print "

"; print_r($e); print "
";
return;
}

echo "DONE";


(Vladimir) #4

SOrry for being brief, I'm tired of looking for a solution for this so much, I hardly know what I am writing.....
1.My node is up, I can see the stats when I call curl localhost:9200
2.I opened 9200 port completely for everyone
3.I DID notice that I have an SSL error when I try to call: curl https://localhost:9200
4.I don't user any kind of user/pass
5.So I don't have this problem either, I think.

So regarding 3. That's the probable cause, what do you recommend I do? thanks!


(Zachary Tong) #5

No problem, here to help :slight_smile: As an aside, if you run into issues in the future feel free to drop a ticket at the ES-PHP repo...I tend to notice those faster.

Hmm, do you know what kind of error you are getting? Usually curl will spew some error code ("Curl error 7", etc) which can help debug the issue.

Are you using Shield? Elasticsearch doesn't have SSL support by default, so if you are trying to access a non-Shield node, SSL is probably failing because it doesn't speak SSL :slightly_smiling:


(Vladimir) #6

I don't strictly need to use https, I thought maybe the PHP API client always uses it. If per default it doesn't (when I don't specify it in the setHosts method call), then something else is the problem, since I did try that (not calling the setHosts method) and got the same result. I also tried explicitly stating the host as ["http://localhost:9200"] - by calling this array in the setHosts method - to no avail.


(Vladimir) #7

I am getting:
curl: (35) SSL connect error
when I try to run:
curl https://localhost:9200


(Zachary Tong) #8

Ok yeah, SSL won't work unless you have Shield installed.

Can you paste your code? Also the starting snippet of your ES server log? It may be something wrong with the server, e.g. binding the wrong port.


(Vladimir) #9

Hi, I already copied and pasted the whole code to you. Which code exactly do you mean? Here is the snippet of the whole log, from the moment I close the server and run it again until the error hapens - it looks like it has not been even touched by my code, so this is not really useful:

[2016-01-27 21:51:11,405][INFO ][node ] [Black Goliath] stopping ...
[2016-01-27 21:51:11,465][INFO ][node ] [Black Goliath] stopped
[2016-01-27 21:51:11,466][INFO ][node ] [Black Goliath] closing ...
[2016-01-27 21:51:11,470][INFO ][node ] [Black Goliath] closed
[2016-01-27 21:51:16,682][INFO ][node ] [Pip the Troll] version[1.4.2], pid[21971], build[927caff/2014-12-16T14:11:12Z]
[2016-01-27 21:51:16,683][INFO ][node ] [Pip the Troll] initializing ...
[2016-01-27 21:51:16,687][INFO ][plugins ] [Pip the Troll] loaded [], sites []
[2016-01-27 21:51:19,698][INFO ][node ] [Pip the Troll] initialized
[2016-01-27 21:51:19,698][INFO ][node ] [Pip the Troll] starting ...
[2016-01-27 21:51:19,827][INFO ][transport ] [Pip the Troll] bound_address {inet[/0:0:0:0:0:0:0:0:9300]}, publish_address {inet[/172.31.49.3:9300]}
[2016-01-27 21:51:19,864][INFO ][discovery ] [Pip the Troll] elasticsearch/Lc0Jw6O6Q2eeuQD0L8eiCA
[2016-01-27 21:51:23,642][INFO ][cluster.service ] [Pip the Troll] new_master [Pip the Troll][Lc0Jw6O6Q2eeuQD0L8eiCA][ip-172-31-49-3][inet[/172.31.49.3:9300]], reason: zen-disco-join (elected_as_master)
[2016-01-27 21:51:23,697][INFO ][http ] [Pip the Troll] bound_address {inet[/0:0:0:0:0:0:0:0:9200]}, publish_address {inet[/172.31.49.3:9200]}
[2016-01-27 21:51:23,697][INFO ][node ] [Pip the Troll] started
[2016-01-27 21:51:24,582][INFO ][gateway ] [Pip the Troll] recovered [2] indices into cluster_state


(Zachary Tong) #10

Oops, sorry, skimmed past your code on accident. It looks good :slightly_smiling:

Based on your ES log, I think the problem may be that ES is binding to IPv6 port. That can sometimes cause problems based on local configurations.

Try disabling IPv6 by forcing binding to the IPv4 loopback. Add this to your elasticsearch.yml and restart:

network.host: _non_loopback:ipv4_

Does that fix it for you?


(Vladimir) #11

No, it doesn't.


(Vladimir) #12

IE. I still have the same error, instead of some meaningful message about deleting the index.


(Zachary Tong) #14

Hm. Can you try both localhost:9200 and 127.0.0.1:9200 ? I ran into that issue on my Mac recently after the El Capitan update, something about the loopback devices got confused.

What platform are you on, btw?

Are you on the most recent version of ES-PHP (v2.1.4)?


(Vladimir) #15

I tried 127.0.0.1 too - no success.
Server is Centos. I need it on Centos (as I mentioned earlier). Our server is running on Centos. How can I know the version of the PHP API? Anyway, I remember I tried using previous versions, because I did use it before. I always get the same error. I can tell you which exact subversion I use, but I am sure it is version 2...


(Zachary Tong) #16

Gah, I'm really sorry...juggling issues on the forum in down-time of another task. Sorry for being distracted.

You can check your composer.lock file to see the currently used version. I'd recommend updating to most recent of ES-PHP, just to help rule out bugs in the client library.

Do you use SELinux policies on centos? Are those configured to allow "non-standard" ports? I've seen situations where libcurl is denied access to non-standard ports due to the SELinux policy, but regular curl commands (through the binary) work fine.

Otherwise I'm really not sure, will continue thinking about it. Sorry this has been such a hassle :confused:


(Vladimir) #17

Well, if you installed ES on centos, I am guessing you will be in big shproblem as am I. Thanks for the help though! :slight_smile:


(Vladimir) #18

Hi, I am sorry, it seems I mixed two servers, the one thatI need is centos and it doesn't even respond to curl localhost:9200, it just throws this error:
curl: (7) couldn't connect to host
Can you help me again, I need tis server up and running more than the one I asked you about earlier. I apologize for the mixup once again. Can you tell me what can be the reason for not even curl localhost:9200 being able to pull through?


(Vladimir) #19

Hi, I reinstalled ES server using the latest tar ball, and everything works fine now.......thanks for your time :slight_smile:


(Zachary Tong) #20

Sure, np. Glad you finally sorted it out! I wonder what the underlying problem was...


(system) #21