Finding the PID of a Process Using a Specific Port in Linux

In Linux, managing network services and troubleshooting network issues often require you to identify which processes are listening on specific ports. This is crucial for system administrators, especially when dealing with conflicts or security audits. Here, we’ll explore various methods to find the Process ID (PID) of a process using a specific port.

Method 1: Using netstat

netstat (network statistics) is a command-line tool that displays network connections, routing tables, interface statistics, masquerade connections, and multicast memberships. Although it’s been replaced by more modern tools like ss, it’s still widely used and available in most Linux distributions.

Command:

netstat -ltnp | grep ':PORT'

• -l lists listening sockets.

• -t shows TCP connections.

• -n displays addresses and port numbers in numerical form.

• -p shows the PID and the name of the program to which each socket belongs.

Example: To find the PID of the process listening on port 8080:

netstat -ltnp | grep ':8080'

Output:

tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      1234/process_name

Here, 1234 is the PID of the process.

Method 2: Using ss

ss (socket statistics) is a utility to investigate sockets. It’s faster and provides more information than netstat.

Command:

ss -ltnp | grep ':PORT'

• -l shows listening sockets.

• -t displays TCP sockets.

• -n avoids converting addresses into names.

• -p shows the process using the socket.

Example: To find the PID of the process using port 8080:

ss -ltnp | grep ':8080'

Output:

LISTEN 0      128          *:8080                     *:*                   users:(("process_name",pid=1234,fd=7))

Here, 1234 is the PID.

Method 3: Using lsof

lsof (List Open Files) is a powerful command used to list information about files opened by processes. An open “file” can be a regular file, a directory, a block device, a network socket, etc.

Command:

lsof -i :PORT

Example: To find the PID of the process using port 8080:

lsof -i :8080

Output:

COMMAND   PID     USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
process_name 1234 user    7u  IPv4  12345      0t0  TCP *:http-alt (LISTEN)

Here, 1234 is the PID.

For Linux system administrators, knowing how to find the PID of a process using a specific port is essential for managing services and resolving conflicts. The ss command is recommended for modern systems due to its speed and detailed output, but netstat and lsof are also valuable tools depending on your specific needs and system configuration.

Each method has its strengths, and choosing the right one depends on your specific requirements and the details you need about the processes and their network activities.

Related Reading

• Differences Between nohup, disown, and & in Linux
• Archive & Compression utilities
• Bulk File Renaming on Linux: rename, vidir, fd
• Directory FileCount
• Essential Linux Commands for Daily Use

When These Commands Lie to You

The tools above work great — until they don’t. Here are the gotchas that will waste your afternoon if you don’t know about them.

You Need sudo (Or You’ll Miss Things)

The -p flag on both ss and netstat only shows process info for processes you own. Running as a regular user, any socket owned by root or another service account will show up without a PID — just a blank or a *. You’ll stare at the output, conclude nothing is listening, and be completely wrong.

Always run these with sudo when you’re doing real troubleshooting:

sudo ss -ltnp | grep ':8080'
sudo lsof -i :8080

Without sudo, lsof silently drops rows it can’t fully describe. You might get partial output, you might get nothing. Either way, you’ll draw the wrong conclusion.

UDP Ports Are Invisible

All three commands in the main section use -t for TCP. If you’re chasing something like a DNS resolver, a game server, or a metrics exporter that binds UDP, you’ll get zero results and think the port is free. Add -u to catch UDP:

# TCP + UDP, all listening sockets
ss -ltnup | grep ':53'

Or with lsof, toss -i udp at it:

sudo lsof -i udp:53

The Process Already Died (But the Port Is Still “In Use”)

You kill a process, try to restart your service, and get address already in use. The old socket is in TIME_WAIT state — the kernel is holding it for up to 2 minutes to handle any late-arriving packets. ss will show it, but there’s no PID to kill because the process is already gone.

# Check for TIME_WAIT sockets on a port
ss -tn state time-wait | grep ':8080'

You can either wait it out, or if you control the application, set SO_REUSEADDR on the socket. If you’re in a hurry and it’s your dev box: sudo sysctl net.ipv4.tcp_tw_reuse=1 will help, but don’t do that on production without knowing what you’re signing up for.

Containers and Namespaces Will Break Your Brain

If you’re running Docker or any other container runtime, ss and netstat on the host will show container ports only if they’re actually mapped to the host interface (e.g., -p 8080:8080). A container binding port 8080 internally with no host mapping is completely invisible from host tools. You’ll need to either:

• Exec into the container: docker exec -it <container> ss -ltnp
• Or check Docker’s port mapping directly: docker ps --format "table {{.Names}}\t{{.Ports}}"

Same idea applies if you’re poking around inside LXC containers or VMs — you’re looking at the wrong network namespace entirely.