🚨 Logstash Error: 'Address already in use' — Cause, Fix, and Troubleshooting Guide

Overview

Listening inputs — tcp, udp, beats, http, syslog — bind a local port when the pipeline starts. If that port is already held by another process, the JVM cannot bind it and the plugin enters an unrecoverable-error restart loop:

[ERROR][logstash.javapipeline][main] A plugin had an unrecoverable error. Will restart this plugin.
  Pipeline_id:main
  Plugin: <LogStash::Inputs::Tcp port=>5000, host=>"0.0.0.0">
  Error: Address already in use
  Exception: Java::JavaNet::BindException

BindException: Address already in use is an operating-system error, not a Logstash config error — the port is occupied. The plugin keeps restarting because Logstash assumes the condition may clear, but if a second Logstash instance, a stale process, or another service owns the port, it never does. The pipeline never receives events until the port is freed or the input is moved.

Symptoms

• Address already in use / Java::JavaNet::BindException on a tcp, udp, beats, http, or syslog input.
• The offending plugin logs Will restart this plugin repeatedly, in a tight loop.
• The input never accepts connections; upstream shippers (Beats, syslog senders) see connection refused or nothing at all.
• Often appears right after a reload/restart, a crash that left a process behind, or after adding a second pipeline in pipelines.yml.
• With a privileged port (<1024), the failure may instead be a permission error even though nothing else holds the port.

Common Root Causes

• A second Logstash instance — two services (or a manual bin/logstash run plus the systemd unit) both try to bind the same port.
• Two pipelines binding the same port — two entries in pipelines.yml each define an input on, say, 5044.
• A stale leftover process — a previous Logstash crash or a hung reload left a JVM holding the port.
• Another service owns the port — an unrelated app (or a container publishing the port) is already listening there.
• Privileged port without permission — binding a port below 1024 (e.g. 514 for syslog) as the non-root logstash user without the capability to do so.

How to diagnose

Find exactly which process holds the port. ss names the PID and program:

# Who is listening on the port from the error (5000 here; use :5044 for beats)
sudo ss -ltnp | grep ':5000'

# Same for UDP inputs (syslog/udp)
sudo ss -lunp | grep ':514'

Confirm whether more than one Logstash is running:

systemctl status logstash --no-pager
ps -ef | grep -i '[l]ogstash'

Check pipelines.yml for two pipelines binding the same port — a very common self-inflicted cause:

# /etc/logstash/pipelines.yml — DUPLICATE port 5044 across pipelines
- pipeline.id: beats-a
  path.config: "/etc/logstash/conf.d/beats-a.conf"   # input beats { port => 5044 }
- pipeline.id: beats-b
  path.config: "/etc/logstash/conf.d/beats-b.conf"   # input beats { port => 5044 }  <-- collision

Watch the log to confirm the restart loop and which plugin/port is failing:

sudo tail -f /var/log/logstash/logstash-plain.log | grep -Ei 'BindException|Address already in use|restart this plugin'

Fixes

If a stale Logstash process is squatting the port, stop the service cleanly and kill the leftover, then start fresh:

sudo systemctl stop logstash
# find and kill the stale JVM still holding the port
sudo ss -ltnp | grep ':5000'
sudo kill "$(sudo ss -ltnp | sed -n 's/.*pid=\([0-9]*\).*:5000.*/\1/p')"
sudo systemctl start logstash

If two pipelines collide, give each input a distinct port in its own config:

# /etc/logstash/pipelines.yml
- pipeline.id: beats-a
  path.config: "/etc/logstash/conf.d/beats-a.conf"   # beats { port => 5044 }
- pipeline.id: beats-b
  path.config: "/etc/logstash/conf.d/beats-b.conf"   # beats { port => 5045 }

# /etc/logstash/conf.d/beats-b.conf
input {
  beats {
    port => 5045
    host => "0.0.0.0"
  }
}

For a privileged port (< 1024) run behind a higher port, or grant the capability to the service. Prefer a high port with a proxy, but if you must bind directly, add the capability to the unit:

sudo systemctl edit logstash

# drop-in: allow binding privileged ports without running as root
[Service]
AmbientCapabilities=CAP_NET_BIND_SERVICE

Then reload and restart, and confirm the bind succeeds with no more restarts:

sudo systemctl daemon-reload && sudo systemctl restart logstash
sudo ss -ltnp | grep -E ':(5044|5045|514)'
sudo tail -f /var/log/logstash/logstash-plain.log | grep -Ei 'BindException|Starting input'

What to watch out for

• Address already in use is an OS-level bind failure — no amount of config-syntax fixing helps until the port is free.
• Never run a manual bin/logstash alongside the systemd service on the same host; they will fight over input ports.
• Give every listening input across all pipelines a unique port; duplicated ports in pipelines.yml are the most common cause.
• SO_REUSEADDR does not save you here — two live listeners cannot share the same port, so pick distinct ones.
• For syslog on 514, prefer a high port (e.g. 5514) behind a load balancer/proxy over granting CAP_NET_BIND_SERVICE, to keep Logstash unprivileged.
• After a crash, always verify the old JVM is gone (ss -ltnp) before starting a new instance, or you will loop.

Related

• Another instance already running (lock)
• Beats input connection reset
• PipelineAction::Create failed