Kibana preElasticsearchProxy - Port Conflict Issue

Hi, am going though upgrade of cluster to ES/Kib 7.14 and RoR 1.34.

We hit this error message:

[ROR] - serve.js - intercepting config
[21:05:44:877] [info][plugins][ReadonlyREST][preElasticsearchProxy] Pre-Elasticsearch-proxy will listen on 127.0.0.1:7740
[ROR] - serve.js - intercepting config
FATAL Error: Port 7730 is already in use. Another instance of Kibana may be running!

after a while, figured out that there is a Logstash container running on same server that was using 7730 - temporarily shutting this down allowed Kibana (also in a container) to start properly. All containers on this server are using host networking mode, which may be a factor…?

I don’t think I can easily change the port on the Logstash side without impact on other things. Is there a way I can control the ports RoR is using for these proxies?

Thanks,

Adrian

1 Like

also - meant to say that the mention of 7740 and then later 7730 in the log output confused me for a bit! For future release, might be good to update logging that it is attempting to bind both ports -

“Pre-Elasticsearch-proxy will listen on 127.0.0.1:7740 and 127.0.0.1:7730” ?

thx :slight_smile:

1 Like

Yeah we probably need to surface those internal ports range in the configuration, as we literally cannot use unix sockets because Elastic won’t support it by choice (they refuse to include features that are only available for single node use).

Ok, thanks @sscarduzio - so right now there’s no way to control/configure?

If so, can you advise on how the ports are currently selected, so we can see if other systems could be configured to avoid? I.e. is it fully predictable/deterministic that for my configuration the ports will be 7730 and 7740? In our config the primary Kibana port is 7720, so I guess the proxy ports are being derived from that?

We bind two servers: one in kibana listen port + 10 and the other in kibana listen port + 20. Those ports should be free.

Maybe we should just add a mechanism to check before bind, and use the next free port. As these servers are anyway only bound to localhost, and are tied by a shared secret. No use to surface their existence to the user at all.

sounds good! In the interim, we’ll look at what we can do to avoid those ports in other systems. Thanks!

1 Like