ElasticSearch 5.0.0-aplha4 won't start without setting vm.max_map_count

Elastic Stack Elasticsearch
1

Hi Team
I wish to update my ES version from 2.3 to 5.0.0-alpha4 to be able to use Ingest nodes and remove Logstash out of the question. But it seems ES 5.x version won't start without me setting vm.max_map_count to 262144. I don't want to set that value..I am okay with default value 65530. Can anyone guide me how to get ES 5.x started without tampering memory settings at all. I don't have access to root user on the host on which i wish to install ES.

Error:
java.lang.UnsupportedOperationException: seccomp unavailable: CONFIG_SECCOMP not compiled into kernel, CONFIG_SECCOMP and CONFIG_SECCOMP_FILTER are needed
at org.elasticsearch.bootstrap.Seccomp.linuxImpl(Seccomp.java:347)
at org.elasticsearch.bootstrap.Seccomp.init(Seccomp.java:616)
[2016-08-08 07:49:55,436][INFO ][node ] [data-cum-ingest-node] initializing ...
[2016-08-08 07:49:56,048][INFO ][plugins ] [data-cum-ingest-node] modules [percolator, lang-mustache, lang-painless, reindex, aggs-matrix-stats, lang-expression, ingest-common, lang-groovy], plugins []
[2016-08-08 07:49:56,601][INFO ][env ] [data-cum-ingest-node] heap size [7.9gb], compressed ordinary object pointers [true]
[2016-08-08 07:49:57,582][INFO ][node ] [data-cum-ingest-node] initialized
[2016-08-08 07:49:57,582][INFO ][node ] [data-cum-ingest-node] starting ...
[2016-08-08 07:49:57,635][ERROR][bootstrap ] [data-cum-ingest-node] Exception
java.lang.RuntimeException: bootstrap checks failed
max virtual memory areas vm.max_map_count [65530] likely too low, increase to at least [262144]
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:178)
at org.elasticsearch.node.Node.start(Node.java:373)
at org.elasticsearch.bootstrap.Bootstrap.start(Bootstrap.java:193)
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:252)
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)
Suppressed: java.lang.IllegalStateException: max virtual memory areas vm.max_map_count [65530] likely too low, increase to at least [262144]
at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
at org.elasticsearch.bootstrap.BootstrapCheck.check(BootstrapCheck.java:126)

2

We've added a number of bootstrap checks in 5.0 to ensure that environments are correctly setup, take a look at https://www.elastic.co/guide/en/elasticsearch/reference/master/bootstrap-checks.html

3

Is there a bypass to this..My real requirement is to use Ingest node feature..which i believe is only available in ES 5.x versions..Can we bypass the checks which would require commands being executed using root..The motivation behind using Ingest node is to be able to do away with logstash as its heavy and does not gives me desired performance.

4

You can disable these checks with the bootstrap.ignore_system_bootstrap_checks node setting. But to be clear, it is highly advised to fix the problem rather than disabling the check!

5

I tried using bootstrap.ignore_system_bootstrap_checks: true but it still checks. I had ES_JAVA_OPTS set to -Xms1g -Xmx8g and it started crying.
EDIT: Not sure why startup memory should be same as maximum memory as part of bootstrap check

6

Hi,

Did you resolve this issue? I'm having the same issue with vm.max_map_count.
I tried to set bootstrap.ignore_system_bootstrap_checks to true but it still has the issue. :frowning:

7

There are lots of checks internally done, which makes ES 5.x difficult to configure. So i left it there itself and switched back to using ES 2.x versions. I wonder if people would like ES 5.x version because of so many constraints.

8

Note that these checks are being done for your protection. 2.x does not have any of these checks which means you're just ignoring the things that could eventually result in shard allocation failure, nodes leaving the cluster, etc. And those things may happen to you at 3am, taking your production cluster down. These checks are certainly annoying, which we acknowledge but ultimately they're there to make sure you don't have a miserable experience including data loss months down the line, having ignored/deferred something we know causes problems.

We have a list of the checks to address before you get into production at https://www.elastic.co/guide/en/elasticsearch/reference/current/_heap_size_check.html

4 Likes
9

I would recommend this checks be optional for those who want to deploy in prod. Users like me who use this only non prod env for QA purposes and who are okay with certain loss of data its fine, cause deployment in our use case is not full fledge.

10

Agreed! These checks need to be optional.

11

You may also want to read https://www.elastic.co/blog/bootstrap_checks_annoying_instead_of_devastating

12

Problem here:

Anyway, we think that 99% of folks that have "real" "production" installation of Elasticsearch will bind to a non-local IP address. We also think that most folks that bind to a non-local IP address are either setting up a "real" installation of Elasticsearch or are running Elasticsearch in a container or VM, resumably set up using a configuration management system like Puppet/Chef/Ansible/Salt/bash-cripts-and-duct-tape.

Unfortunately, I'm in the 1% of guys who want to run ES 5.x in a Docker container. :frowning:

But it's okay, I can deal with it on Linux Docker host by setting vm.max_map_count=262144. The only problem I have now is my Windows Docker host (boot2docker), the setting vm.max_map_count=262144 is reset after I reboot my machine. :disappointed_relieved:

13

Thanks, I know how to make the setting persistent on Boot2docker now.

docker-machine ssh default
sudo vi /var/lib/boot2docker/profile
# Add this line into the profile file
sysctl -w vm.max_map_count=262144
14

This particular requirement only shows how lame ES developers are and how poorly they understand what they are doing. Under any circumstances this should not be made mandatory.

Also, whoever told you that "99% of all folks run this crap in production" had no idea what he was talking about either. Unfortunately, this piece of garbage is installed on lots of internal CI / development system. And its widespread use is the only thing that perpetuates itself in this very sector.

15

Another 1% docker user here, please remove this memory check. I shouldn't have to make modifications to the host machine to run the application in a docker container, that defeats the whole purpose.

16

Ideally i think one could simply turn off the bootstrap memory check, I see the value of the bootstrap checks, and I understand why you made running them mandatory, but since ES in a docker container is always detected to be running in 'production' mode, it can be rather problematic

17

We will happily listen to and carefully consider constructive criticism. But posting confrontationally like this establishes you as an adversary rather than a collaborator, is an ineffective way to make a point, and contributes to building a poor reputation for yourself.

I say this hoping that it will have a positive impact on you but even if not I state it for the benefit of the entire community that we expect civil discourse here.

3 Likes
18

just realized (by reading the excellent docs!) that I can make these checks non-fatal by unsetting the network.host configuration and then that indicates it's not in production mode.

1 Like