Tomcat java.net.BindException: Address already in use: the connector never starts

You restart Tomcat. The JVM comes up. The process check goes green. Then catalina.out shows:

SEVERE [main] org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to initialize component [Connector[HTTP/1.1-8080]]
java.net.BindException: Address already in use

The JVM is alive, but the HTTP connector never bound its port. No traffic is served. Health checks that only verify the PID report healthy while every client gets connection refused.

This is the “Connector Binding vs Process Alive” trap: the JVM stays up after a connector init failure, so process-based monitoring passes while nothing listens. The failure modes are narrow. A stale Tomcat still holding 8080 or 8443, a port conflict with another service, or a previous shutdown that did not release the socket. Each has a different fix, and conflating them produces the wrong remediation.

This article walks diagnosis from the BindException line in catalina.out to the actual holder of the port, then covers the connector attributes (bindOnInit, socket.soReuseAddress) that change when and whether the bind happens.

What this means

Tomcat starts connectors through a lifecycle. With the default bindOnInit="true", the connector binds its server socket during the init() phase, before the rest of the lifecycle starts. If bind() throws java.net.BindException, the connector goes into FAILED state, but the Server, Service, Engine, and Host keep starting. The JVM process is up. Other connectors, if any, may also be up. Only the failed connector’s port is dark.

The error in catalina.out typically reads:

ERROR [main] org.apache.coyote.http11.Http11NioProtocol Failed to initialize end point associated with ProtocolHandler ["http-nio-8080"]
java.net.BindException: Address already in use

followed by a LifecycleBase line naming the failed component. The exact logger class varies by Tomcat version and connector protocol (Http11NioProtocol on current releases, Http11Protocol on older lines), but the exception class is invariant.

The critical operational point: process-alive is a necessary, not sufficient, condition. A pgrep -f 'org.apache.catalina.startup.Bootstrap' returning a PID tells you the JVM exists. It does not tell you port 8080 is bound. The only reliable signal that Tomcat is serving is a successful TCP connect and HTTP round trip against the connector’s port.

Common causes

The first three account for almost every real-world occurrence. The fourth bites teams running parallel instances during blue/green or canary deploys. The fifth is rarer but produces the same exception class.

Quick checks

These are all read-only and safe to run on a production host.

# Confirm the BindException is for the port you expect
grep -A 3 'BindException' "$CATALINA_BASE/logs/catalina.out" | tail -30

# What is currently holding the port (process info via -p; needs root for other users' PIDs)
ss -tnlp 'sport = :8080'

# All Tomcat default ports at once
ss -tnlp '( sport = :8080 or sport = :8443 or sport = :8005 or sport = :8009 )'

# Find every JVM running Tomcat bootstrap on this host
pgrep -af 'org.apache.catalina.startup.Bootstrap'

# Count TIME-WAIT sockets on the connector port (rapid-restart signature)
ss -tan 'sport = :8080' | awk '/TIME-WAIT/' | wc -l

# Confirm a TCP connect to the port actually works
nc -vz -w 2 127.0.0.1 8080

# See which interface the port is bound on (0.0.0.0 vs 127.0.0.1)
ss -tnl 'sport = :8080'

# Read the connector block to confirm address and bindOnInit
grep -A 8 '<Connector' "$CATALINA_BASE/conf/server.xml"

If ss -tnlp 'sport = :8080' returns nothing, the port is free in the listening sense and the BindException is either stale (the holder already exited) or about TIME-WAIT. If it returns a row, the users:... field names the holding process and PID.

How to diagnose it

The decision tree below collapses the diagnosis into a single pass.

flowchart TD
    A[catalina.out: BindException on port N] --> B[ss -tnlp sport = :N]
    B --> C{Process holding port?}
    C -->|Yes, java with catalina.startup.Bootstrap| D[Stale Tomcat instance]
    C -->|Yes, other process| E[Port conflict with another service]
    C -->|No listener| F[ss -tan sport = :N]
    D --> G[Confirm PID, stop cleanly, restart]
    E --> H[Move service or change Tomcat port]
    F --> I{Many TIME-WAIT sockets?}
    I -->|Yes| J[Wait, or set socket.soReuseAddress=true]
    I -->|No| K[Check server.xml address attribute]

Work through it in order.

1. Pull the exact failing port from catalina.out. The exception names the component, not always the port number explicitly. The Connector[HTTP/1.1-8080] form gives you the port. If it is https-jsse-nio-8443, the failing port is 8443.

2. Check the holder with ss -tnlp 'sport = :N'. This is the single most useful command. If a row appears, you have a name and a PID. If no row appears, the bind failure is not a live listener.

3. If the holder is another Java process, run pgrep -af 'catalina.startup.Bootstrap'. More than one PID means a stale Tomcat. This is common during deployments where the previous instance was not fully stopped before the new one started. Cross-check with ps -o pid,etime,cmd -p <pid> to see how long the stale process has been running.

4. If the holder is a non-Java process, it is a port conflict. Identify the service with ps -o pid,cmd -p <pid>. Common offenders on 8080 are nginx, httpd, Jenkins, and reverse proxies. Where systemd manages the holder, systemctl status <pid> names the unit.

5. If nothing is listening, check TIME-WAIT with ss -tan 'sport = :N' | grep TIME-WAIT | wc -l. A high count after a forced kill means the kernel has not yet released the socket. This typically self-resolves within the TIME-WAIT interval (roughly 60 seconds on default Linux).

6. If neither a listener nor TIME-WAIT explains it, inspect server.xml. The address attribute on the <Connector> element pins the bind interface. If it names an address the host does not own (a VIP that has not failed over, a removed bridge, a container network that is not yet up), the bind fails with the same exception class.

Metrics and signals to monitor

The synthetic TCP check is the only one that catches this failure mode without parsing logs. A simple nc -vz -w 2 127.0.0.1 8080 on a short interval, run from the same host, surfaces the outage within seconds of the failed restart.

Fixes

Stale Tomcat process

Identify the PID from ss -tnlp or pgrep -af 'catalina.startup.Bootstrap'. Prefer a clean shutdown: shutdown.sh, or your service manager’s stop, lets Tomcat release sockets gracefully and flush logs. Reserve kill -9 for processes that ignore normal shutdown. It skips the cleanup path and increases the chance of TIME-WAIT holding the port for the next start.

If the stale process is from a previous deployment step that did not wait for shutdown to complete, fix the deployment script to poll for process exit before starting the new instance. A pgrep loop with a timeout is usually enough.

Port conflict with another service

Either move the conflicting service or change the Tomcat connector port. Changing Tomcat is usually safer because the conflicting service is often infrastructure (nginx, httpd) that other things depend on. Edit server.xml, change the port attribute on the <Connector>, and restart. Remember to also update the shutdown port (8005) and AJP port (8009) if you are running multiple instances on the same host. All three must be unique per instance, or the second instance will fail in the same way.

Previous shutdown left TIME-WAIT

Linux holds a socket in TIME-WAIT for roughly 60 seconds after the local side closes. If you restart inside that window, the new bind can fail. Two remedies:

• Wait. The simplest fix. Most production restart procedures already take longer than 60 seconds end to end, which is why this only bites on rapid restart loops and crashloop-style orchestrations.
• Set socket.soReuseAddress="true" on the connector. SO_REUSEADDR allows binding over sockets in TIME-WAIT on Linux. Tomcat applies the JVM default if you do not set the attribute explicitly. Setting it removes ambiguity across JDK distributions.

The companion attribute is bindOnInit. The default true binds during init(), which is what produces the early BindException on startup. Setting bindOnInit="false" defers the bind to the start() phase. It does not prevent port conflicts, but it changes when in the lifecycle the failure surfaces, which can matter for orchestration that expects clean separation of init and start phases. Known quirk: with bindOnInit="false", the socket is not always reliably unbound on connector stop, which can leave the port stuck for the next start.

Wrong bind interface

Check the address attribute in server.xml. If it names a specific IP, that IP must exist on a local interface at bind time. VIPs that have not failed over, removed bridges, and containers whose network is not yet up all produce the same exception class. Bind to 0.0.0.0 (the default when address is omitted) if you do not need interface pinning, or move the bind behind a reverse proxy that handles interface management.

Prevention

• Replace process-only health checks with port checks. A pgrep is not an availability signal. A TCP connect against the connector port plus an HTTP round trip is.
• Set socket.soReuseAddress="true" explicitly on every connector if your operations include rapid restarts. Do not rely on the JVM default.
• Document port assignments per host. Stale Tomcat and port conflict are both symptoms of poor host-level port hygiene. A simple inventory (8080, 8005, 8009, 8443 per instance) prevents the multi-instance variant.
• Make deployment scripts poll for clean shutdown. The most common cause of stale Tomcat is a deploy script that starts the new instance before the old one has fully exited.
• Alert on BindException in catalina.out directly. It is a string match, it is unambiguous, and it fires within seconds of the failed restart.

How Netdata helps

• TCP and HTTP synthetic checks on the connector port are the only reliable detector of “process alive, port not bound.” Per-second checks page the moment the port stops accepting connections, even when the JVM is still running.
• Per-second process metrics show the JVM starting and the port check failing in the same window, making the BindException pattern obvious without log digging.
• Log scanning on catalina.out surfaces the BindException line as an event the instant it is written, with the connector name and port in context for correlation.
• Correlation across signals (process up, port down, BindException in log, connector state FAILED) collapses the diagnosis to a single timeline rather than four separate tools.

Related guides

• How Tomcat actually works in production: a mental model for operators
• Tomcat process not running: crashes, OOM-kills, and failed restarts
• Tomcat monitoring checklist: the signals every production instance needs
• Tomcat monitoring maturity model: from survival to expert