Bootstrap.system_call_filter to false not able to configure cluster

Elastic Stack Elasticsearch
1

Hi,

Iam using the Elasticsearch 5.5.2, and Iam not able to configure cluster. I dont see my nodes talking to each other. I tried using the following configuration in my elasticsearch.yml.

I tried changing the transport.host: to my server ip, but doing so the bootstrap check fails,
unable to install syscall filter: java.lang.UnsupportedOperationException: seccomp unavailable: CONFIG_SECCOMP not compiled into kernel, CONFIG_SECCOMP and C ONFIG_SECCOMP_FILTER are needed at org.elasticsearch.bootstrap.SystemCallFilter.linuxImpl(SystemCallFilter.java:363) ~[elasticsearch-5.5.2.jar:5.5. 2]

Iam using Red Hat Enterprise Linux Server release 6.8 (Santiago) OS.

if I set bootstrap.system_call_filter: false and having the transport.host: localhost, the node is getting started but not able to talk to other nodes in other servers in the same network

my question is if SecComp fails then can we still run the elasticsearch in the cluster mode?

my elasticsearch.yml

`#

#action.destructive_requires_name: true

network.host: ${HOSTNAME}
network.host: X.X.X.X
transport.host: localhost
transport.tcp.port: 9300

#bootstrap.system_call_filter: false

Enabling CORS - for production we need to restrict domain wise

http.cors.allow-origin: "/.*/"
http.cors.enabled: true
http.cors.allow-headers: "X-Requested-With,content-type,authorization"
http.cors.allow-credentials: true

Enabling clustering more

cluster.name: logsearch
node.name: "node_1"
node.master: true
node.data: true
#discovery.zen.ping.multicast.enabled: false

discovery.zen.minimum_master_nodes: 1
discovery.zen.ping.unicast.hosts: ["X.X.X.X:9300","X.X.X.X:9300"]
`

2

You cross-posted this to the open source repository too: https://github.com/elastic/elasticsearch/issues/26461. Please do not do that, it fractures discussions. Additionally, please post questions here first, and save the repository for verified bugs and feature requests. When in doubt, post here first.

3

Hi Jason, sorry about that, the reason I posted here is after adding bootstrap.system_call_filter: false in the elasticsearch.yml and having the transport.host: localhost, the clustering is not getting enabled between the nodes so does it mean that if SECCOMP is not compiled into kernel cant we enable the cluster setup inspite of setting bootstrap.system_call_filter: false

4

As I explained in the GitHub issue: no. If you set bootstrap.system_call_filter to false it neuters the system call filter bootstrap check, it will pass everytime; the point is that now you're explicitly accepting the risk of Elasticsearch not sandboxing itself via seccomp. That is not the cause of your nodes being unable to cluster. I'm not sure exactly what you're trying to do but if you have nodes on multiple machines that you want to cluster, then they can't cluster with transport.host set to localhost.

5

Hi Jason,

Iam trying to set up a cluster for nodes running on multiple machine, Iam planning to have one master node and two slave node, when I try to start the master node elasticsearch I was getting the error unable to install syscall filter: java.lang.UnsupportedOperationException: seccomp unavailable..., so I included bootstrap.system_call_filter: false in the masternode elastisearch.yml and now as you mentioned that setting transport.host : localhost will not work, I tried pointing the transport.host: x.x.x.x (server ip address), but dodoing so Iam getting the below exception

bound or publishing to a non-loopback or non-link-local address, enforcing bootstrap checks
ERROR: [2] bootstrap checks failed

is there any other settings I need to do to make the nodes running on multiple machines to cluster ?

log trace:

[2017-09-01T04:28:54,578][INFO ][o.e.p.PluginsService ] [sit077] loaded plugin [x-pack]
[2017-09-01T04:28:57,065][DEBUG][o.e.a.ActionModule ] Using REST wrapper from plugin org.elasticsearch.xpack.XPackPlugin
[2017-09-01T04:28:58,038][INFO ][o.e.x.m.j.p.l.CppLogMessageHandler] [controller/39566] [Main.cc@128] controller (64 bit): Version 5.5.2 (Build 0d83940bb9d682) Copyright (c) 2017 Elasticsearch BV
[2017-09-01T04:28:58,112][INFO ][o.e.d.DiscoveryModule ] [sit077] using discovery type [zen]
[2017-09-01T04:28:59,369][INFO ][o.e.n.Node ] [sit077] initialized
[2017-09-01T04:28:59,369][INFO ][o.e.n.Node ] [sit077] starting ...
[2017-09-01T04:28:59,759][INFO ][o.e.t.TransportService ] [sit077] publish_address {x.x.x.x:9300}, bound_addresses {x.x.x.x:9300}
[2017-09-01T04:28:59,774][INFO ][o.e.b.BootstrapChecks ] [sit077] bound or publishing to a non-loopback or non-link-local 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]
[2017-09-01T04:28:59,785][INFO ][o.e.n.Node ] [sit077] stopping ...
[2017-09-01T04:28:59,833][INFO ][o.e.n.Node ] [sit077] stopped
[2017-09-01T04:28:59,834][INFO ][o.e.n.Node ] [sit077] closing ...
[2017-09-01T04:28:59,850][INFO ][o.e.n.Node ] [sit077] closed

my elasticsearch.yml for the above run is as below

network.host: ${HOSTNAME}
#transport.host: localhost
transport.host: x.x.x.x
transport.tcp.port: 9300

bootstrap.system_call_filter: false

http.cors.allow-origin: "/.*/"
http.cors.enabled: true
http.cors.allow-headers: "X-Requested-With,content-type,authorization"
http.cors.allow-credentials: true

cluster.name: logsearch
node.name: "sit077"
node.master: true
node.data: true
#discovery.zen.ping.multicast.enabled: false
#discovery.zen.ping.unicast.hosts: ["sit077.dc.bc.com:9300","sit076.dc.bc.com:9300"]
discovery.zen.ping.unicast.hosts: ["x.x.x.x:9300","y.y.y.y:9300"]
discovery.zen.minimum_master_nodes: 1
6

You still have failing 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]
7

setting bootstrap.system_call_filter: false wont take care of suppressing those two failed bootstrap checks?

8

No. Why would it? Those are completely unrelated issues.

9

Ok, is there anyway to suppress these checks with our own risk?

10

No, there is not.

11

Thanks a lot Jason for your quick responses, much appreciated !!

12

You're welcome. In case you have not seen it, it might be worthwhile for you to read our blog post about the bootstrap checks.

13

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.