“lsof -i” – Reveal Critical Details About Your Network Sockets

Table of Contents#

1. What Is lsof?
2. What Are Network Sockets?
3. Why lsof -i?
4. Getting Started: Install lsof and Basic Syntax
5. Decoding the lsof -i Output: What Each Column Means
6. Advanced Filtering: Narrow Down Results Like a Pro
7. Common Use Cases: Solve Real-World Problems
8. Best Practices: Use lsof -i Effectively and Safely
9. Troubleshooting: Fix Common lsof -i Headaches
10. lsof vs ss: When to Use Which
11. Conclusion: Why lsof -i Is Indispensable
12. References

What Is lsof?#

lsof (List Open Files) is a Unix/Linux command that lists all open files on a system. In Unix-like OSes, everything is a file—including network sockets, pipes, and devices. lsof exposes which processes are using which files, making it a powerful tool for debugging and security. Originally developed by Vic Abell in 1991, lsof is now maintained on GitHub and supports Linux, FreeBSD, macOS, NetBSD, OpenBSD, and Solaris. The latest release is version 4.99.6 (March 2026).

Note: On Linux, a newer tool called lsfd (part of the util-linux package) is emerging as a modern alternative. However, lsof remains the standard across all Unix-like systems and is still the go-to tool for network socket diagnostics.

What Are Network Sockets?#

A network socket is an endpoint for communication between two processes over a network. It’s defined by:

• Protocol: TCP (connection-oriented, reliable) or UDP (connectionless, fast).
• IP Address: Local (e.g., 192.168.1.5) or remote (e.g., example.com).
• Port: A number (1–65535) that identifies the service (e.g., 80 for HTTP, 443 for HTTPS).

Sockets have states that reflect their activity (e.g., LISTEN for waiting on connections, ESTABLISHED for active communication). Understanding these states is key to interpreting lsof -i output.

Why lsof -i?#

The -i flag filters lsof output to show only network sockets (IP-based, e.g., TCP/UDP over IPv4/IPv6). This turns lsof from a general file-listing tool into a network-specific diagnostic powerhouse.

2. Getting Started: Install lsof and Basic Syntax#

Step 1: Install lsof#

lsof is pre-installed on most Unix-like systems (macOS, Linux servers). If not, install it with:

• Debian/Ubuntu: sudo apt install lsof
• RHEL/CentOS/Fedora: sudo dnf install lsof
• macOS: Already included (verify with lsof -v).

Step 2: Basic Syntax#

The core syntax for lsof -i is:

lsof -i [options]

Key Flags to Pair With -i#

Example: Basic Network Socket List#

Run this command to see all active network sockets:

sudo lsof -i -nP

• sudo: Required to see processes owned by other users (e.g., root).
• -n: No DNS lookup (faster).
• -P: Show port numbers (avoid confusion with service names).

3. Decoding the lsof -i Output: What Each Column Means#

lsof -i output is dense—let’s break down each column with a sample output (annotated for clarity):

COMMAND  PID     USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
apache2  1234    root    4u  IPv4  12345      0t0  TCP *:80 (LISTEN)  # 1
apache2  1235 www-data    5u  IPv4  12346      0t0  TCP 192.168.1.5:80->192.168.1.10:54321 (ESTABLISHED)  # 2
sshd     5678    root    3u  IPv6  67890      0t0  TCP *:22 (LISTEN)  # 3
curl     9012    user    7u  IPv4  90123      0t0  TCP 192.168.1.5:43210->93.184.216.34:443 (ESTABLISHED)  # 4

Column Breakdown#

1. COMMAND: Name of the process using the socket (e.g., apache2, sshd).
2. PID: Unique ID of the process (kill it with sudo kill <PID>).
3. USER: User who owns the process (e.g., root for system services).
4. FD: File Descriptor—an integer that identifies the socket to the process.
   • The suffix (e.g., u) indicates access mode: u = read/write (most common for sockets).
5. TYPE: IP version (IPv4 or IPv6).
6. DEVICE: Device number (rarely useful for sockets).
7. SIZE/OFF: Size or offset (0 for sockets, since they’re stream-based).
8. NODE: Inode number (irrelevant for sockets).
9. NAME: The most critical column—it shows:
   • Listening Sockets: *:<port> (e.g., *:80 = listening on all interfaces for port 80).
   • Established Sockets: <local-IP>:<local-port>-><remote-IP>:<remote-port>.
   • State: In parentheses (e.g., LISTEN, ESTABLISHED).

4. Advanced Filtering: Narrow Down Results Like a Pro#

The real power of lsof -i lies in filtering—use these patterns to eliminate noise and find exactly what you need.

Filter by Protocol (TCP/UDP)#

Target TCP or UDP sockets:

# Show TCP sockets only
lsof -i TCP
 
# Show UDP sockets only (e.g., DNS on port 53)
lsof -i UDP:53

Filter by Port#

Find which process is using a specific port (most common use case):

# Show processes using port 80 (HTTP)
sudo lsof -i :80
 
# Show processes using ports 80–90 (range)
sudo lsof -i :80-90

Filter by IP Address#

Target connections to/from a specific IP:

# Show connections to 192.168.1.10 (remote host)
lsof -i @192.168.1.10
 
# Show connections from 10.0.0.5 (local host)
lsof -i @10.0.0.5

Filter by Socket State#

Focus on sockets in a specific state (e.g., LISTEN for open ports):

# Show all listening ports (critical for security audits)
sudo lsof -i STATE:LISTEN -nP
 
# Show only established connections
lsof -i STATE:ESTABLISHED

Combine Filters#

Use multiple filters to drill down. By default, lsof ORs multiple filters together—use -a to AND them:

# Show TCP connections on port 443 (HTTPS) from user "www-data"
sudo lsof -i TCP:443 -u www-data -nP
 
# AND logic: show files by user "nginx" AND process name "nginx"
sudo lsof -u nginx -a -c nginx
 
# Show IPv6 TCP connections to example.com (93.184.216.34)
lsof -i [email protected]:443

Output PIDs Only (Scripting)#

The -t flag returns just the PID, making it composable with other commands:

# Kill whatever is using port 3000
kill $(lsof -t -i :3000)
 
# Force kill if needed (use with caution)
kill -9 $(lsof -t -i :3000)
 
# Count network connections per process
lsof -i -n -P | awk '{print $1}' | sort | uniq -c | sort -rn | head -10

5. Common Use Cases: Solve Real-World Problems#

Let’s apply lsof -i to practical scenarios you’ll encounter daily.

Use Case 1: Fix “Address Already in Use” Errors#

Scenario: You try to start a web server on port 3000 but get:
Error: listen EADDRINUSE: address already in use :::3000

Solution: Find the process using port 3000 and kill it:

# Step 1: Identify the PID
sudo lsof -i :3000
 
# Sample Output:
# COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
# node    1234 user    7u  IPv6  12345      0t0  TCP *:3000 (LISTEN)
 
# Step 2: Kill the process
sudo kill -9 1234

Use Case 2: Monitor Active SSH Connections#

Scenario: You want to see who’s connected to your server via SSH (port 22).

Solution:

sudo lsof -i TCP:22 -nP

Sample Output:

COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
sshd    5678 root    3u  IPv6  67890      0t0  TCP *:22 (LISTEN)
sshd    7890 root    4u  IPv6  78901      0t0  TCP 192.168.1.5:22->10.0.0.10:54321 (ESTABLISHED)

• The first line shows sshd listening on port 22.
• The second line shows an active connection from 10.0.0.10 (remote IP) to your server.

Use Case 3: Audit Open Ports for Security#

Scenario: You need to verify which ports your server is exposing to the internet.

Solution: List all listening ports (no DNS, port numbers only):

sudo lsof -i STATE:LISTEN -nP | awk '{print $9}' | sort -u

Sample Output:

*:22
*:80
*:443

• These are the ports your server is “listening” on—ensure they’re intentional (e.g., 22 for SSH, 80/443 for web traffic).

Use Case 4: Troubleshoot Connectivity Issues#

Scenario: A client can’t connect to your server on port 443 (HTTPS).

Solution: Verify your server is listening on port 443:

sudo lsof -i TCP:443 -nP

• If no output: Your web server (e.g., Nginx) isn’t running—start it with sudo systemctl start nginx.
• If output exists: Check firewall rules (e.g., ufw on Ubuntu) to ensure port 443 is open.

Use Case 5: Find Deleted Files Still Consuming Disk Space#

Scenario: df shows high disk usage, but du doesn't match. A deleted file is still held open by a process—Linux won't reclaim the space until the file descriptor is closed.

Solution: Find deleted files still held open:

sudo lsof | grep deleted | awk '{print $1, $2, $7, $9}'

• The output shows the process name, PID, size, and path of deleted files.
• Restart the process holding the large file to reclaim disk space.

Quick fix for a specific mount:

sudo lsof +D /var/log | grep deleted

• This is a common issue after log rotation when processes don't release old log files.

6. Best Practices: Use lsof -i Effectively and Safely#

Follow these rules to avoid mistakes and get the most out of lsof -i:

1. Run as Root#

Many system processes (e.g., sshd, nginx) are owned by root. Without sudo, you’ll miss critical information:

# Bad: Misses root-owned processes
lsof -i :80
 
# Good: Shows all processes
sudo lsof -i :80

2. Use Specific Filters#

Avoid broad commands like lsof -i—they produce too much noise. Instead, narrow down with ports, protocols, or states:

# Bad: Shows all network sockets (overwhelming)
lsof -i
 
# Good: Shows only listening TCP ports (focused)
sudo lsof -i TCP -nP -s TCP:LISTEN

3. Combine with Other Tools#

Pipe lsof -i output to grep, awk, or sort for better readability:

# Show only established connections, sorted by remote IP
lsof -i STATE:ESTABLISHED -nP | grep -v LISTEN | sort -k 9

4. Understand Socket States#

Learn common states to interpret output correctly:

• LISTEN: Waiting for incoming connections (open port).
• ESTABLISHED: Active connection between two endpoints.
• TIME_WAIT: Connection closed but socket remains open to handle lingering packets.
• CLOSE_WAIT: Remote host closed the connection—local process hasn’t cleaned up.

5. Audit Regularly#

Run sudo lsof -i STATE:LISTEN -nP weekly to:

• Ensure no unauthorized ports are open.
• Detect rogue processes (e.g., malware listening on a random port).

6. Avoid Overuse#

lsof iterates over all open files—on busy systems, it can be resource-intensive. Use narrow filters to minimize impact.

7. Use -r for Monitoring#

Use the -r flag to repeat lsof output at regular intervals—useful for watching connections open and close in real time:

# Refresh every 5 seconds
sudo lsof -i -n -P -r 5
 
# Or use watch for a cleaner display
watch -n 2 'sudo lsof -i -n -P -sTCP:LISTEN'

7. Troubleshooting: Fix Common lsof -i Headaches#

Problem 1: No Output#

Cause:

• No sockets match your filter (e.g., port 80 isn’t in use).
• You don’t have permission to see the process (run with sudo).

Fix:

# Verify permissions
sudo lsof -i :80
 
# Check if the port is in use (alternate method)
ss -tuln | grep :80

Problem 2: Slow Output#

Cause: lsof is scanning too many files (broad filter).

Fix: Add more specific filters (e.g., port, protocol):

# Slow: Scans all TCP sockets
lsof -i TCP
 
# Fast: Scans only TCP port 80
lsof -i TCP:80

Problem 3: Confusing IPv6 Output#

Cause: IPv6 addresses (e.g., [::1] for loopback) are harder to read.

Fix: Use -i 6 to focus on IPv6 or -i 4 for IPv4:

# Show IPv6 sockets only
lsof -i 6
 
# Show IPv4 sockets only
lsof -i 4

Problem 4: Machine-Readable Output#

Cause: You need to parse lsof output in a script (e.g., for automation).

Fix: Use the -F flag to generate structured output:

# Output PID (p) and NAME (n) for TCP port 80
lsof -F pn -i TCP:80
 
# Sample Output:
p1234
n*:http
p5678
n192.168.1.5:80->192.168.1.10:54321

lsof vs ss: When to Use Which#

For network-specific work, ss (socket statistics) is faster and more feature-complete than lsof -i. Both are valuable, but they serve different purposes:

When to use lsof -i:

• You need to know which process (command name, user) is using a port
• You're debugging a "device is busy" or "file in use" error alongside network issues
• You need to cross-reference network activity with file descriptors or libraries

When to use ss:

• You need a fast snapshot of all listening ports or connections
• You're inspecting TCP internals (congestion, timers, memory buffers)
• You're on a busy system where lsof is too slow

Example comparison:

# lsof: detailed process info
sudo lsof -i TCP:22 -n -P
# Shows: sshd, PID, root, FD 3u, IPv6, LISTEN
 
# ss: fast snapshot
ss -tlnp | grep :22
# Shows: LISTEN, PID, users:(("sshd",...))

For a complete network diagnostic workflow, combine both: use ss for a quick overview, then lsof to dig into specific processes.

8. Conclusion: Why lsof -i Is Indispensable#

lsof -i is more than a command—it's a network troubleshooting and security tool that every sysadmin and developer should master. With it, you can:

• Fix "port in use" errors in seconds.
• Monitor active connections for anomalies.
• Audit open ports to harden your server.
• Troubleshoot connectivity issues like a pro.
• Reclaim disk space from deleted files held open by processes.

The key to success is specificity: Use narrow filters to cut through noise and focus on what matters. Combine lsof -i with other tools (e.g., ss, ufw) for a complete network diagnostic suite.

Commands to keep in muscle memory:

• sudo lsof -i -n -P — Network connection overview
• sudo lsof -i :PORT — Find what's using a port
• sudo lsof | grep deleted — Find phantom disk usage
• sudo lsof +D /path — Find processes holding a mount busy
• kill $(lsof -t -i :PORT) — Kill the process on a port

9. References#

1. lsof Man Page: man7.org — Official Linux manual page for lsof
2. lsof GitHub Repository: lsof-org/lsof — Current home of lsof development and releases
3. TCP Socket States: RFC 793 (Transmission Control Protocol)
4. Network Sockets: Linux Man Pages (socket)
5. lsof Guide (Red Hat): How to use the lsof command to troubleshoot Linux
6. lsof Guide (LinuxBlog.io): lsof Command in Linux: Find Open Files, Ports, and Processes

Let me know in the comments if you have questions or want to share your favorite lsof -i trick!

— Your Name