Elasticsearch: error message for heap size bootstrap check does not guide user

[djschny]

Elasticsearch version: 5.0.0-alpha3 internal RC 1

JVM version: 1.8.0_74-b02

OS version: OSX 10.11.4

Description of the problem including expected versus actual behavior:
After binding elasticsearch to a public facing network interface the bootstrap checks kick in. They are great and usually very directly and immediately allow the user to know what setting to set immediately. For example with the discovery.zen.minimum_master_nodes. However the heap size check states there is a problem but does not guide the user towards an example command line argument or property to set to remediate the problem as clear as the other bootstrap checks do. Not the end of the world, but definitely I think some quick wording could help remediate and provide a better user experience.

Steps to reproduce:

1. Startup elasticsearch binding to 0.0.0.0
2. Notice the message for heap size does not directly guide the user on how to set them to be the same.

Provide logs (if relevant):

djschny:elasticsearch-5.0.0-alpha3 djschny$ bin/elasticsearch -E network.host=0.0.0.0 -E discovery.zen.minimum_master_nodes=1
[2016-05-24 21:49:34,540][INFO ][node                     ] [Jim Hammond] version[5.0.0-alpha3], pid[43525], build[b3a8c54/2016-05-24T18:55:09.209Z]
[2016-05-24 21:49:34,541][INFO ][node                     ] [Jim Hammond] initializing ...
[2016-05-24 21:49:35,141][INFO ][plugins                  ] [Jim Hammond] modules [percolator, lang-mustache, lang-painless, ingest-grok, reindex, lang-expression, lang-groovy], plugins []
[2016-05-24 21:49:35,172][INFO ][env                      ] [Jim Hammond] using [1] data paths, mounts [[/ (/dev/disk1)]], net usable_space [148.2gb], net total_space [464.7gb], spins? [unknown], types [hfs]
[2016-05-24 21:49:35,172][INFO ][env                      ] [Jim Hammond] heap size [1.9gb], compressed ordinary object pointers [true]
[2016-05-24 21:49:37,310][INFO ][node                     ] [Jim Hammond] initialized
[2016-05-24 21:49:37,311][INFO ][node                     ] [Jim Hammond] starting ...
[2016-05-24 21:49:37,388][INFO ][transport                ] [Jim Hammond] publish_address {192.168.43.85:9300}, bound_addresses {[::]:9300}
Exception in thread "main" java.lang.RuntimeException: bootstrap checks failed
initial heap size [268435456] not equal to maximum heap size [2147483648]; this can cause resize pauses and prevents mlockall from locking the entire heap
    at org.elasticsearch.bootstrap.BootstrapCheck.check(BootstrapCheck.java:125)
    at org.elasticsearch.bootstrap.BootstrapCheck.check(BootstrapCheck.java:85)
    at org.elasticsearch.bootstrap.BootstrapCheck.check(BootstrapCheck.java:65)
    at org.elasticsearch.bootstrap.Bootstrap$5.validateNodeBeforeAcceptingRequests(Bootstrap.java:183)
    at org.elasticsearch.node.Node.start(Node.java:323)
    at org.elasticsearch.bootstrap.Bootstrap.start(Bootstrap.java:198)
    at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:257)
    at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:96)
    at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:91)
    at org.elasticsearch.cli.SettingCommand.execute(SettingCommand.java:54)
    at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:91)
    at org.elasticsearch.cli.Command.main(Command.java:53)
    at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:70)
    at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:63)
Refer to the log for complete error details.

Ultimately I did the following to make this work:

ES_JAVA_OPTS="-Xms1024m -Xmx1024m" bin/elasticsearch -E network.host=0.0.0.0 -E discovery.zen.minimum_master_nodes=1

So perhaps guidance towards the ES_JAVA_OPTS example I think would go a long way. Once again minor in regards to technical, but I believe huge in regards to getting to a running state quicker.

[jasontedor]

Thanks for reporting. I think that all the bootstrap checks could use additional guidance. I will work to improve.

Do note though that the goal isn't to get to a running state quickly but to get to a viable production state.

[jasontedor]

I pushed bootstrap check docs in #18605.

[DreadPirateRob]

For others finding this via google search, I fixed this by editing /etc/elasticsearch/jvm.options file from this:

-Xmx2g

to this:

-Xmx2g

[ebuildy]

That means the release doesnot work without this fix ? (I had this "bug", @DreadPirateRob "fix" did the trick, thanks you).

[jasontedor]

The next pre-release of Elasticsearch will have the defaults configured such that the default configuration will no longer run into this issue.

[vanga]

These bootstrap checks are big big hindrance in getting a cluster up.

[dadoonet]

@vanga I'd recommend reading https://www.elastic.co/blog/bootstrap_checks_annoying_instead_of_devastating