Systems troubleshooting guide8 min read

How to find the process listening on a port

A port conflict or unknown listener is best handled as an identification problem first. Find the listening socket, map it to a process, and verify that process before stopping or reconfiguring anything.

Reviewed by the Terminaster editorial team · Updated 2026-07-26

What you will take away

A listening socket is more specific evidence than searching a process list by name.
Use ss on Linux and lsof on Linux or macOS to map a port to a process.
Process details may be hidden unless you own the process or have sufficient privileges.
Verify the executable, arguments, user, and service manager before sending a signal.

Start with the listening socket, not a guessed name

Applications can change names, spawn workers, or run inside service managers and containers. The kernel’s socket table directly answers whether something is listening on a local TCP port.

Record the protocol as well as the number. TCP port 3000 and UDP port 3000 are separate endpoints, and an established client connection is not the same as a listening server socket.

Use ss to inspect a Linux listener

The ss flags below request listening TCP sockets, numeric addresses, and process information. A port filter keeps the result focused. Without sufficient permission, ss may show the socket but omit another user’s process details.

The Local Address:Port column tells you where the service is bound. A loopback address accepts only same-host traffic; a specific interface address is narrower than a wildcard bind.

-l selects listening or unconnected server sockets.
-t and -u select TCP and UDP respectively.
-n prevents service-name lookup so the numeric port remains visible.
-p asks for process information when permissions allow it.

Find a TCP listener on Linux

ss -ltnp 'sport = :3000'

# If no TCP listener appears, check UDP separately
ss -lunp 'sport = :3000'

Use lsof on Linux or macOS

lsof can select network files by protocol and port. Restricting the TCP state to LISTEN avoids confusing a client connection with the server that owns the port.

The output includes a process ID, command name, user, and file descriptor. Treat a truncated command name as a clue; inspect the PID before drawing a conclusion.

Find a listener with lsof

lsof -nP -iTCP:3000 -sTCP:LISTEN

# Inspect a returned PID without changing it
ps -p 12345 -o pid=,ppid=,user=,etime=,command=

Verify how the process is managed

A development server you launched from the current shell can usually be stopped through that shell. A production daemon may be supervised by systemd, launchd, Docker, Kubernetes, or another manager that will restart it after a direct signal.

If the port is unexpectedly occupied, inspect the parent process, executable path, working directory where available, and service or container metadata. Reconfigure the intended service or stop the owning unit through its manager instead of blindly killing a PID.

1Confirm the socket protocol, local address, port, and LISTEN state.
2Record the PID and owning user shown by ss or lsof.
3Inspect the full command and parent PID with ps.
4Determine whether a service manager or container owns the process.
5Choose a reversible stop or configuration change appropriate to that owner.

Common questions

Frequently asked questions

Why does ss show the port but no process name?

Process metadata is permission-sensitive. If another user owns the socket, your account may see the listener without its PID or command. Use elevated access only when you are authorized and actually need that metadata.

Why do lsof and ss show more than one process?

Processes can share a listener through inherited file descriptors or options such as SO_REUSEPORT. Containers and proxy processes can also add layers. Inspect the process relationships instead of assuming duplicate output is an error.

Should I use netstat instead?

Existing systems may provide netstat, but ss is the modern Linux tool and lsof is convenient across Linux and macOS. Available netstat flags and process visibility differ by operating system.

Keep learning

Sources and next steps

Linux ss(8) manualDocuments socket selection, state filters, process output, and expressions.lsof options documentationMaintained documentation for network selectors, output controls, and process filtering.

Related mental models

Port and socket

A port is a 16-bit number in a transport protocol such as TCP or UDP. A socket is a kernel communication object that a process usually accesses through a file descriptor. An internet socket can bind to a local protocol, IP address, and port; a connected TCP socket also records the remote address and port.

Process and PID

A process is an operating-system execution context for a running program, including its memory, credentials, and open resources. A process ID (PID) is the number the OS uses to identify that process within a PID namespace for its current lifetime.

IP address and network interface

A network interface is an operating-system attachment point for sending and receiving network packets, whether backed by hardware or software. An IP address and prefix assigned to an interface identify an IP endpoint and its on-link network within a particular network configuration.