Skip to main content

ElasticSearch - BindTransportException: Failed to bind to 9300-9400

After installing a new ElasticSearch cluster I updated the elasticsearch.yml to expose it outside the local Virtual Machine.

This is how the updated elasticsearch.yml looked like:

There is definitely something wrong with this configuration as ElasticSearch refused to start.

A look at the log file showed the following error information:

[2022-05-09T09:45:02,104][ERROR][o.e.b.Bootstrap] [SERVER1] Exception

org.elasticsearch.transport.BindTransportException: Failed to bind to 192.168.0.1:[9300-9399]

at org.elasticsearch.transport.TcpTransport.bindToPort(TcpTransport.java:489) ~[elasticsearch-8.2.0.jar:8.2.0]

at org.elasticsearch.transport.TcpTransport.bindServer(TcpTransport.java:450) ~[elasticsearch-8.2.0.jar:8.2.0]

at org.elasticsearch.transport.netty4.Netty4Transport.doStart(Netty4Transport.java:147) ~[?:?]

at org.elasticsearch.xpack.core.security.transport.netty4.SecurityNetty4Transport.doStart(SecurityNetty4Transport.java:96) ~[?:?]

at org.elasticsearch.xpack.security.transport.netty4.SecurityNetty4ServerTransport.doStart(SecurityNetty4ServerTransport.java:59) ~[?:?]

at org.elasticsearch.common.component.AbstractLifecycleComponent.start(AbstractLifecycleComponent.java:48) ~[elasticsearch-8.2.0.jar:8.2.0]

at org.elasticsearch.transport.TransportService.doStart(TransportService.java:274) ~[elasticsearch-8.2.0.jar:8.2.0]

at org.elasticsearch.common.component.AbstractLifecycleComponent.start(AbstractLifecycleComponent.java:48) ~[elasticsearch-8.2.0.jar:8.2.0]

at org.elasticsearch.node.Node.start(Node.java:1164) ~[elasticsearch-8.2.0.jar:8.2.0]

at org.elasticsearch.bootstrap.Bootstrap.start(Bootstrap.java:272) ~[elasticsearch-8.2.0.jar:8.2.0]

at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:367) [elasticsearch-8.2.0.jar:8.2.0]

at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:166) [elasticsearch-8.2.0.jar:8.2.0]

at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:157) [elasticsearch-8.2.0.jar:8.2.0]

at org.elasticsearch.common.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:81) [elasticsearch-8.2.0.jar:8.2.0]

at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:112) [elasticsearch-cli-8.2.0.jar:8.2.0]

at org.elasticsearch.cli.Command.main(Command.java:77) [elasticsearch-cli-8.2.0.jar:8.2.0]

at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:122) [elasticsearch-8.2.0.jar:8.2.0]

at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:80) [elasticsearch-8.2.0.jar:8.2.0]

Caused by: java.net.BindException: Cannot assign requested address: bind

at sun.nio.ch.Net.bind0(Native Method) ~[?:?]

at sun.nio.ch.Net.bind(Net.java:555) ~[?:?]

at sun.nio.ch.ServerSocketChannelImpl.netBind(ServerSocketChannelImpl.java:337) ~[?:?]

at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:294) ~[?:?]

at io.netty.channel.socket.nio.NioServerSocketChannel.doBind(NioServerSocketChannel.java:134) ~[?:?]

at io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:562) ~[?:?]

at io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1334) ~[?:?]

at io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:506) ~[?:?]

at io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:491) ~[?:?]

at io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:973) ~[?:?]

at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:260) ~[?:?]

at io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:356) ~[?:?]

at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164) ~[?:?]

at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:469) ~[?:?]

at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:503) ~[?:?]

at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986) ~[?:?]

at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[?:?]

at java.lang.Thread.run(Thread.java:833) ~[?:?]

[2022-05-09T09:45:02,104][WARN ][stderr] [SERVER1] org.elasticsearch.transport.BindTransportException: Failed to bind to 192.168.0.1:[9300-9399]

[2022-05-09T09:45:02,104][WARN ][stderr] [SERVER1] Likely root cause: java.net.BindException: Cannot assign requested address: bind

Although I updated the network.host address to a non loopback address, using a local IP (192.168.0.1) was not correct. Instead I should use 0.0.0.0 to use the default network interface.

To fix the error I updated the network.host setting:

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.

VS Code Planning mode

After the introduction of Plan mode in Visual Studio , it now also found its way into VS Code. Planning mode, or as I like to call it 'Hannibal mode', extends GitHub Copilot's Agent Mode capabilities to handle larger, multi-step coding tasks with a structured approach. Instead of jumping straight into code generation, Planning mode creates a detailed execution plan. If you want more details, have a look at my previous post . Putting plan mode into action VS Code takes a different approach compared to Visual Studio when using plan mode. Instead of a configuration setting that you can activate but have limited control over, planning is available as a separate chat mode/agent: I like this approach better than how Visual Studio does it as you have explicit control when plan mode is activated. Instead of immediately diving into execution, the plan agent creates a plan and asks some follow up questions: You can further edit the plan by clicking on ‘Open in Editor’: ...