For those landing on this post trying to resolve these errors for yourself (whereas I'm only asking about what they mean), I have provided my steps at the bottom of this post for getting rid of the errors.
Installed elasticsearch and can access from localhost, but having timeout issues when trying to connect from remote machine. Trying to fix throws error that before trying to fix, were just warnings.
This other post (Installed elastic search on server but cannot connect to it if from another machine) may be outdated as when inspecting elasticsearch.yml, there appears to be no network.bind_host variable and the post seems to be referring to an older version. But following it as much as possible, running
[me@mapr07 config]$ netstat -ntlp | awk '/[j]ava/'
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp6 0 0 127.0.0.1:9200 :::* LISTEN 21109/java
tcp6 0 0 ::1:9200 :::* LISTEN 21109/java
shows that we are binding to localhost and "if you are binding to localhost (i.e. 127.0.0.1), you can only accept connections from the localhost, not over the network."(https://stackoverflow.com/a/24057311/8236733) (I don't know much networking stuff).
From the elasticsearch docs (https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-network.html#advanced-network-settings), tried setting the network.bind_host variable in $ES_HOME/config/elasticsearch.yml to 0.0.0.0 (like in the original post). However, after rersterting elasticsearch, we see the output:
[2018-05-15T14:49:54,395][INFO ][o.e.n.Node ] [TjtCCG8] starting ...
[2018-05-15T14:49:54,603][INFO ][o.e.t.TransportService ] [TjtCCG8] publish_address {127.0.0.1:9300}, bound_addresses {[::]:9300}
[2018-05-15T14:49:54,620][INFO ][o.e.b.BootstrapChecks ] [TjtCCG8] bound or publishing to a non-loopback address, enforcing bootstrap checks
ERROR: [2] bootstrap checks failed
[1]: max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536]
[2]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
[2018-05-15T14:49:54,641][INFO ][o.e.n.Node ] [TjtCCG8] stopping ...
[2018-05-15T14:49:54,670][INFO ][o.e.n.Node ] [TjtCCG8] stopped
[2018-05-15T14:49:54,670][INFO ][o.e.n.Node ] [TjtCCG8] closing ...
[2018-05-15T14:49:54,701][INFO ][o.e.n.Node ] [TjtCCG8] closed
I don't get how this happens and I also don't get why it is even a real problem, since it previously threw this error as a warning when bound to localhost and would run anyway, eg.
[2018-05-15T15:01:32,017][INFO ][o.e.n.Node ] [TjtCCG8] starting ...
[2018-05-15T15:01:32,283][INFO ][o.e.t.TransportService ] [TjtCCG8] publish_address {127.0.0.1:9300}, bound_addresses {[::1]:9300}, {127.0.0.1:9300}
[2018-05-15T15:01:32,303][WARN ][o.e.b.BootstrapChecks ] [TjtCCG8] max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536]
[2018-05-15T15:01:32,304][WARN ][o.e.b.BootstrapChecks ] [TjtCCG8] max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
[2018-05-15T15:01:35,372][INFO ][o.e.c.s.MasterService ] [TjtCCG8] zen-disco-elected-as-master ([0] nodes joined), reason: new_master {TjtCCG8}{TjtCCG8LQOWOE2HNFdcLxA}{ik_q1XYnTk-BBJXcBMNK_A}{127.0.0.1}{127.0.0.1:9300}
My question is, why does this happen? In both cases there appears to be the same number of file descriptors and vm space being used, so why is it that when binding to 0.0.0.0 that amount is no longer just a warning level but an error?
For those landing on this post trying to resolve these errors for yourself (whereas I'm only asking about what they mean), I have provided my steps below for getting rid of the errors.
Doing some quick googling, the docs advise running the command
sudo su
ulimit -n 65536
su elasticsearch (dont exit *back* to elasticsearch session, since new limit only applies to current session (which ends if you exit))
to address the max file descriptors [4096] for elasticsearch process is too low error, since
Elasticsearch uses a lot of file descriptors or file handles. Running out of file descriptors can be disastrous and will most probably lead to data loss. Make sure to increase the limit on the number of open files descriptors for the user running Elasticsearch to 65,536 or higher.
(https://www.elastic.co/guide/en/elasticsearch/reference/current/file-descriptors.html#file-descriptors). Secondly, to address the max virtual memory error, run
(sudo) sysctl -w vm.max_map_count=262144
on linux systems, since
The default operating system limits on mmap counts is likely to be too low, which may result in out of memory exceptions
