When an application fails to start because "address already is in use," you need to find the conflicting process immediately. Whether you're configuring a web server on port 80 or debugging a custom daemon, knowing how to check what's using a port in Linux is an essential troubleshooting skill.
You don't need complex scripts or heavy third-party software to solve this. Linux provides built-in utilities like ss, lsof, and netstat that pinpoint the exact process ID and program name holding a socket. This guide walks through the fastest commands, real-world examples, and precise steps to reclaim your system ports.
Identifying the Active Port Tool: ss
The ss command is the modern successor to netstat. It dumps socket statistics directly from the Linux kernel kernel socket tables, making it significantly faster than older tools when dealing with thousands of active connections.
To check which process is listening on a specific port, combine ss with flags for listening sockets, numerical output, and process details. You'll need elevated privileges to view process names owned by other users.
sudo ss -lntp 'sport = :80'
Breaking down this command helps you remember the syntax:
-l: Displays only listening sockets waiting for incoming connections.-n: Resolves numerical addresses instead of trying to resolve hostnames.-t: Shows TCP sockets.-p: Displays the process name and Process ID (PID) associated with the socket.'sport = :80': Filters the output specifically for source port 80.
If you don't know the exact port number but want to inspect all listening services on your machine, run sudo ss -tulpn. This gives you a complete overview of every open TCP and UDP port alongside its corresponding application.
Using lsof to Trace Open Files and Ports
Linux treats everything as a file, including network sockets. The lsof (List Open Files) utility excels at finding which application has opened a specific network port.
To query a specific port, such as port 3306 for MySQL, use the following syntax:
sudo lsof -i :3306
The output gives you a clean table showing the command name, PID, user, file descriptor, type, and the connection state. Here is what a typical response looks like:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mysqld 1249 mysql 20u IPv6 28379 0t0 TCP *:mysql (LISTEN)
If you only want the raw PID so you can feed it directly into another command or script, combine lsof with the -t flag:
sudo lsof -t -i :8080
This returns just the number—for example, 4192—which makes script automation seamless. If lsof isn't installed on a minimal container or server image, you can install it easily through your package manager, such as sudo apt install lsof on Ubuntu or sudo dnf install lsof on Fedora, referencing the GNU Project utilities guidelines for core software management.
Legacy and Fallback Option: netstat
While netstat has been deprecated in modern Linux distributions for several years, it still exists on many legacy enterprise servers and older Debian or RHEL releases. If ss or lsof aren't available, netstat remains a reliable fallback.
To find what's using port 443 using netstat, run:
sudo netstat -tulnp | grep :443
The flags perform similar functions to ss:
-t: Show TCP ports.-u: Show UDP ports.-l: Show listening ports only.-n: Show numerical addresses.-p: Show the PID and program name.
Because netstat scans the entire socket table before passing data to grep, it can feel sluggish on high-traffic servers with tens of thousands of active connections. Whenever possible, prefer ss.
Terminating the Conflicting Process
Once you've identified the PID hogging your port, you have two choices: stop the service gracefully or kill the process forcefully.
Graceful Termination
Always attempt to stop the application through its init system first. If PID 1249 belongs to an orphaned service or a rogue test script, use the standard kill signal to let the application close open file handles and database connections cleanly:
sudo kill 1249
Forceful Termination
If the process refuses to stop or hangs in an uninterruptible state, send the termination signal -9, which forces the Linux kernel to drop the process immediately:
sudo kill -9 1249
Be cautious when using kill -9 on database engines or production web servers, as abrupt termination can occasionally cause data corruption or leave stale lock files behind. Always check system logs using journalctl -u servicename if an application fails to restart cleanly after freeing its port.
Common Pitfalls During Port Troubleshooting
Sysadmins often run into specific roadblocks when tracking down network listeners. Keep these common mistakes in mind:
- Forgetting sudo privileges: Regular users can view their own processes, but they won't see PIDs owned by root or other system daemons. Always prepend
sudotossandlsofqueries. - Confusing TCP and UDP: If an application listens on UDP port 53 (DNS), running a TCP-only filter won't return any results. Make sure your command checks the correct protocol flag.
- Containerized environments: If you're running Docker or Kubernetes, a port might appear bound on the host machine, but the actual listener lives inside an isolated network namespace. Use
docker psor inspect container port mappings before killing host processes.
Frequently Asked Questions
Why does my command return 'Permission denied' when checking ports?
You are likely running the command as a standard user. Linux restricts regular users from viewing process IDs and command names associated with ports owned by other users or system services. Use sudo to run the command with elevated privileges.
How do I check ports in use by a specific Docker container?
Docker maps container ports to the host system. You can inspect active container bindings by running docker ps to see port forwardings, or use sudo ss -tulpn | grep docker to find which proxy daemon is handling the socket.
What is the difference between ss and netstat?
The ss utility reads socket information directly from the Linux kernel's Netlink socket interface, making it vastly superior in speed and accuracy. netstat parses /proc files and is deprecated in modern Linux distributions.
Can I check remote ports using these local commands?
No. Tools like ss, lsof, and netstat inspect local operating system sockets and listening tables. To check remote ports across a network, use port scanners like nmap or connection testers like nc (netcat).
