Bootstrap Error


Just trying out 5.0.0. On my previous 2.4 instance I had set to as otherwise I couldn't connect to Elasticsearch from logstash.

In 5.0.0, if I make the same change, Elasticsearch won't startup, it says:

[2016-10-31T10:32:58,446][INFO ][o.e.b.BootstrapCheck ] [gbvlixaacas22t] bound or publishing to a non-loopback or non-link-local address, enforcing bootstrap checks
ERROR: bootstrap checks failed

If I don't make this change, Elasticsearch starts up but logstash gives:

Connection refused {:class=>"Manticore::SocketException", :level=>:error}

This is on RHEL.

No problems with the old version.


Read the full log. It will tell you what is wrong.

It says:

[2016-10-31T10:32:58,446][INFO ][o.e.b.BootstrapCheck ] [gbvlixaacas22t] bound or publishing to a non-loopback or non-link-local address, enforcing bootstrap checks
[2016-10-31T10:32:58,458][ERROR][o.e.b.Bootstrap ] [gbvlixaacas22t] node validation exception
bootstrap checks failed

It then only has the usual warnings which I don't plan to change as this is only a tiny test system and the same messages came up in the old version:

max file descriptors [32000] for elasticsearch process likely too low, increase to at least [65536]
max number of threads [1024] for user [uktja] likely too low, increase to at least [2048]
max virtual memory areas vm.max_map_count [65530] likely too low, increase to at least [262144]

What is a node validation exception?

You have to fix all the latest messages.

These type of messages were just warnings in the previous release, is this release more fussy.
Unfortunately I can't change these values, so I guess I can't upgrade.

If you bind to a non-local IP these things are enforced. We explain the reasoning on the PRs and reexplain here. We have no plans at this point to give an opt out flag.

Thanks for the link, it was interesting and I understand the points.

It's disappointing as I now can't test the new version on my dev servers as I'd like,.

If there's a vote at any point, put me down for an opt-out :-). I think it can be left up to me whether I am prepared to risk later issues and I am capable of deciding which of my servers is a test and which is prod.


Same problem here - Trying to run in a container for dev & test purposes, I cannot change the kernel parameters of the host.

I understand the concept, but not giving an opt-out just broke any chance for us to upgrade to 5, across the board.

1 Like

We've just patched the docs to explain a way to opt out that ought to work fine for you. It might take a while to build so here is a link to the fix:

Essentially, set to the non-local IP while keeping at its default. You can't form a cluster but you can test against a single node. If you want a cluster you'll need to make the bootstrap checks happy.


Thanks, I appreciate that. I can at least try it out in a limited way, and that suggestion does indeed work for me.