Linux “Address Already in Use” / Port Conflict Troubleshooting
Find which process owns a TCP or UDP port, understand where it is bound, and resolve the conflict without blindly killing processes.
bind: Address already in use, EADDRINUSE, or a framework-specific equivalent.Fast troubleshooting flow
1 — Find the current TCP listener
sudo ss -lntp | grep ':8080'LISTEN 0 4096 0.0.0.0:8080 0.0.0.0:* users:(("java",pid=18421,fd=73))This says PID 18421 owns a TCP listener on port 8080. 0.0.0.0:8080 means all IPv4 interfaces; 127.0.0.1:8080 would be loopback-only. Replace 8080 with the actual port.
2 — For UDP, use the UDP listener view
sudo ss -lnup | grep ':53'UNCONN 0 0 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=812,fd=14))What to check: protocol, local bind address, port and owning PID/program. A UDP socket appears as UNCONN rather than TCP LISTEN; that is normal. TCP and UDP have separate port spaces, so use the protocol from the application error/configuration.
3 — Inspect the owning process/service
ps -fp <PID>
cat /proc/<PID>/cmdline | tr '\0' ' 'If it is a managed service, use its service manager to inspect ownership/configuration rather than treating the PID as disposable.
4 — Check bind-address conflicts
A service bound to 0.0.0.0:8080 generally occupies that IPv4 port across interfaces, so another service cannot independently bind 127.0.0.1:8080 in the normal case. IPv6 wildcard behavior can vary with socket options/system settings, so inspect the actual ss output instead of guessing.
5 — Choose the correct owner
kill -9 just because a PID owns the port. It can interrupt a production service and the supervisor may immediately restart it. Stop/reconfigure the correct service through its normal control path.Verify
sudo ss -lntp | grep ':8080'LISTEN 0 4096 127.0.0.1:8080 0.0.0.0:* users:(("java",pid=20114,fd=73))What to check: the intended process, protocol, address and port. If clients require remote access, a loopback-only listener may still be wrong even though the conflict is gone. Next: test the application from the relevant client path, not only the socket table.
Confirm the intended process owns the expected address/port, then test the application itself. A listening socket proves a listener exists; it does not prove the application is healthy.