How to Find Which Process Is Using a Port in Linux

You start a service, and it refuses to launch with an error like “bind: address already in use”. Something is already holding the port, but the message does not tell you what. Before you can fix it, you need to map the port back to a process, find its PID, and decide whether to stop it. Linux gives you several tools for this, and each one answers the question in a slightly different way.

This guide shows how to find the process using a port with ss, lsof, fuser, and netstat, and how to stop it once you have the PID.

If you need an inventory of every service accepting connections instead of one specific port, see the guide on checking listening ports in Linux .

Quick Reference #

For printable quick references, see the ss cheatsheet , lsof cheatsheet , and netstat cheatsheet .

Finding the Process with ss #

The ss command is the standard choice on current Linux distributions. It comes from the iproute2 package and supports filters that match an exact port without piping the output through another command.

sudo ss -ltnp 'sport = :80'

State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0      511          0.0.0.0:80        0.0.0.0:*    users:(("nginx",pid=1433,fd=6),("nginx",pid=1432,fd=6))
LISTEN 0      511             [::]:80           [::]:*    users:(("nginx",pid=1433,fd=6),("nginx",pid=1432,fd=6))

Run the command with sudo so ss can show process details for sockets owned by other users. The options provide the following information:

• -l - Show only listening sockets.
• -t - Show TCP sockets.
• -n - Print numeric port numbers instead of resolving service names.
• -p - Show the process that owns each socket.

The sport = :80 expression matches local port 80 exactly, so it does not also return ports such as 8080. In the output above, nginx holds the port. The Process column lists two process IDs because the master process, 1432, opened the socket and passed it to its worker, 1433. Either PID leads you back to the same service. The two rows show that nginx listens on both IPv4 and IPv6.

UDP sockets do not use the TCP LISTEN state. To check a UDP port, replace -t with -u. For example, the following command identifies the process bound to UDP port 53:

sudo ss -lunp 'sport = :53'

State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
UNCONN 0      0            0.0.0.0:53        0.0.0.0:*    users:(("dnsmasq",pid=902,fd=4))

The UNCONN state is normal for a UDP server because UDP does not establish connections before exchanging data.

Finding the Process with lsof #

The lsof command lists open files, including network sockets. Use numeric output and restrict the result to TCP listeners on the port:

sudo lsof -nP -iTCP:80 -sTCP:LISTEN

COMMAND  PID     USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
nginx   1432     root    6u  IPv4  28319      0t0  TCP *:80 (LISTEN)
nginx   1433 www-data    6u  IPv4  28319      0t0  TCP *:80 (LISTEN)

The -nP options prevent hostname and service-name lookups, while -iTCP:80 selects TCP port 80 and -sTCP:LISTEN excludes established connections. The output reports the command, PID, user, and file descriptor. Here lsof gives you the same two nginx processes that ss reported, but it also shows the user each one runs as, which is useful when a master process drops privileges for its workers.

For UDP port 53, use this form:

sudo lsof -nP -iUDP:53

The pattern is the same, except that -iUDP:53 selects the UDP port and there is no state filter, because UDP sockets never enter the LISTEN state.

Finding the Process with fuser #

When you want a PID without the full socket table, fuser provides a short command. Pass the port number followed by the protocol:

sudo fuser 80/tcp

80/tcp:               1432  1433

You get the PID list and nothing else, which makes the plain form easy to pass to another command. To include the user, access type, and command name, add the -v option:

sudo fuser -v 80/tcp

                     USER        PID ACCESS COMMAND
80/tcp:              root       1432 F.... nginx
                     www-data   1433 F.... nginx

The port appears once on the first row, and every process below it belongs to that same port. The ACCESS column describes how each process uses the socket, where F marks it as open for writing.

You must specify tcp or udp because the same numeric port can be used by both protocols.

Finding the Process with netstat #

On older systems you may still find netstat , part of the net-tools package. Use it as a fallback when ss is not available:

sudo netstat -ltnp | grep ':80 '

tcp   0   0 0.0.0.0:80   0.0.0.0:*   LISTEN   1432/nginx: master

The last column ties PID 1432 to the nginx master process, and netstat truncates that name if it grows too long. Unlike ss and lsof, it reports a single process per socket rather than the whole group. The space after :80 in the filter prevents it from matching a longer port number such as 8080. For a UDP port, use -lunp instead of -ltnp.

Inspecting and Stopping the Process #

Once you have the PID, confirm what started the process before stopping it. The following ps command shows the full command and its parent PID:

ps -fp 1432

UID          PID    PPID  C STIME TTY          TIME CMD
root        1432       1  0 07:10 ?        00:00:00 nginx: master process /usr/sbin/nginx

A service manager or container runtime may own the process. In that case, stop it through its manager so it does not immediately start again. For example, stop an Nginx systemd service with:

sudo systemctl stop nginx

For an unmanaged process, send SIGTERM with kill:

sudo kill 1432

SIGTERM asks the process to shut down cleanly. If the process ignores it, you can use sudo kill -KILL 1432 as a last resort, but SIGKILL gives it no opportunity to save state or remove temporary files. For more detail about signals, see the guide on how to kill a process in Linux .

After inspecting the verbose fuser output, you can send SIGTERM to every process using the TCP port:

sudo fuser -k -TERM 80/tcp

The explicit -TERM matters because fuser -k sends SIGKILL by default.

Confirming the Port Is Free #

Run the same ss query after stopping the process:

sudo ss -ltnp 'sport = :80'

If no socket row appears below the header, nothing is listening on TCP port 80 in the current network namespace. If you changed a service configuration instead of stopping it, start the service again and check the new port with the same command.

Troubleshooting #

The port appears but the process name is missing
Run the command with sudo. Without root privileges, these tools may not be able to read details for sockets owned by another user.

ss returns nothing but the application still reports a conflict
Check that you are using the correct protocol. Use -lunp for UDP instead of -ltnp for TCP. The listener may also be inside another network namespace or container, so run the check in the same environment as the application.

The process starts again after you stop it
A service manager or container runtime is restarting it. Stop or reconfigure the systemd service, Docker container, or other supervisor instead of repeatedly killing its PID.

Several PIDs appear for the same port
Some servers use a master process with several workers that share one socket. Other applications can use the SO_REUSEPORT option. Identify the parent service and manage the group instead of stopping one worker at a time.

netstat: command not found
The net-tools package is not installed on many current distributions. Use ss instead.

Conclusion #

Use ss first when you need the process behind a specific port, then turn to lsof or fuser when you need a different view. Inspect the PID and its manager before stopping anything, especially on a production system.

About the authors

Dejan Panovski

Dejan Panovski is the founder of Linuxize, an RHCSA-certified Linux system administrator and DevOps engineer based in Skopje, Macedonia. Author of 800+ Linux tutorials with 20+ years of experience turning complex Linux tasks into clear, reliable guides.

View author page