Linux ss, lsof, and fuser Commands: A Practical Guide

Linux ss lsof fuser commands are essential tools for investigating network connections, open files, busy ports, and processes using system resources. When a Linux server refuses connections, reports that a port is already in use, or prevents a filesystem from being unmounted, these commands can quickly reveal what is happening.

Although their functions sometimes overlap, each command approaches troubleshooting differently. The ss command examines network sockets, lsof connects open files and network endpoints to running processes, and fuser identifies processes using a specific file, directory, mount point, or network port.

Knowing how to combine these Linux troubleshooting commands can save considerable time during daily administration. Instead of restarting services blindly, an administrator can identify the affected resource, locate the responsible process, inspect how it was started, and take the appropriate corrective action.

Why These Commands Belong in Every Administrator’s Toolbox

Linux treats many resources as files or process-owned objects. Network sockets, devices, log files, shared libraries, pipes, and mounted filesystems can all be associated with one or more running processes.

This means that many common operational problems can be reduced to a few practical questions:

• Which process is listening on this port?
• Who is connected to a service?
• Why is a filesystem still busy?
• Which application has a deleted file open?
• What process is preventing an application from starting?
• Is a service listening only locally or on every interface?

The commands covered here can answer all of these questions without requiring a graphical interface or additional monitoring software.

Inspecting Network Sockets with ss

The ss command displays information about network sockets. It is generally considered the modern replacement for netstat and is normally included with the iproute2 package.

Running it without options shows active non-listening sockets:

ss

The output can be extensive, so administrators usually combine it with filters.

Display Listening TCP Ports

To list listening TCP sockets:

ss -ltn

The options have the following meanings:

• -l displays listening sockets.
• -t limits the output to TCP.
• -n prevents hostname and service-name resolution.

Numeric output is preferable during troubleshooting because it shows the real port numbers and avoids delays caused by DNS resolution.

For listening UDP sockets, use:

ss -lun

To display both TCP and UDP listeners with process information:

sudo ss -lntup

The -p option shows the process name, PID, and file descriptor when that information is available. Root privileges are usually required for complete results.

A listening SSH service might appear as:

LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=842,fd=3))

This line shows that the sshd process, PID 842, is listening on TCP port 22 across all IPv4 interfaces.

Find What Is Using a Specific Port

Suppose an application cannot start because TCP port 8080 is already occupied. Use:

sudo ss -ltnp 'sport = :8080'

A frequently used alternative is:

sudo ss -ltnp | grep ':8080'

Note: The native socket filter is better because it selects the exact source port. A simple grep expression could also match values such as 18080.

For UDP port 53:

sudo ss -lunp 'sport = :53'

This is useful when investigating DNS services such as BIND, dnsmasq, or systemd-resolved.

Examine Established Connections

To list established TCP connections:

ss -tn state established

Include process information with:

sudo ss -tnp state established

This can reveal active SSH sessions, database clients, web connections, monitoring agents, and unexpected outbound traffic.

To display connections involving a particular destination:

ss -tn dst 192.168.10.25

To find connections to HTTPS services:

ss -tn 'dport = :443'

To display both client and server connections related to PostgreSQL:

ss -tn '( sport = :5432 or dport = :5432 )'

Investigate TCP States

A quick socket summary is available through:

ss -s

ss -s prints summary socket statistics without enumerating the complete socket list. It is useful for getting a quick view of the overall socket state during an incident.

To inspect sockets in TIME-WAIT:

ss -tn state time-wait

A high number of these sockets may be normal on a busy web server, but it may also indicate a large number of short-lived connections.

To examine incomplete TCP handshakes:

ss -tn state syn-recv

A growing number of SYN-RECV entries can indicate network loss, an overloaded application, firewall problems, or suspicious traffic.

Note: If the issue involves TCP retransmissions or unstable application connections rather than a port conflict, see “How to Investigate TCP Retransmissions on Linux“ for a protocol-level troubleshooting workflow.

During an incident, socket statistics can be monitored continuously:

watch -n 2 "ss -s"

To watch listening ports:

watch -n 1 "ss -ltnp"

This is helpful when a service starts briefly, binds to a port, and then exits.

Finding Open Resources with lsof

The name lsof means “list open files.” Since Linux represents many resources as files, the command can inspect regular files, directories, devices, libraries, pipes, network sockets, and deleted files still held by processes.

On Debian or Ubuntu, install it with:

sudo apt install lsof

On RHEL-based distributions:

sudo dnf install lsof

Identify the Process Using a Port

To find which process is using TCP port 80:

sudo lsof -iTCP:80

To limit the result to listening processes:

sudo lsof -iTCP:80 -sTCP:LISTEN

For UDP port 53:

sudo lsof -iUDP:53

For faster and clearer output, disable hostname and service-name resolution:

sudo lsof -nP -iTCP:443

Note: The -n option disables hostname resolution, while -P preserves numeric port numbers. These options are particularly useful on production systems where DNS may be slow or unavailable.

Inspect Files Opened by a Process

If a Java application is running as PID 2450, for example, list everything it has open:

sudo lsof -p 2450

The result may include configuration files, log files, shared libraries, sockets, devices, and the process working directory.

To show only network resources associated with that PID:

sudo lsof -nP -a -p 2450 -i

The -a option combines the conditions. Without it, lsof may interpret filters as separate alternatives.

Find Who Is Accessing a File

To identify the process using a particular log file:

sudo lsof /var/log/myapp/app.log

To inspect a single directory level:

sudo lsof +d /var/lib/myapp

To search recursively:

sudo lsof +D /var/lib/myapp

Note: Recursive searches can be expensive on large filesystems. Avoid running +D against directories containing millions of files unless it is genuinely necessary.

Locate Deleted Files Consuming Disk Space

One of the most valuable uses of lsof is finding deleted files that are still open.

Deleting a file does not immediately release its disk space when a process still holds an open file descriptor. This often happens when an administrator manually removes a large log file while the application continues writing to it.

Find these files with:

sudo lsof +L1

Another common approach is:

sudo lsof | grep '(deleted)'

The +L1 option is generally more precise because it selects open files with fewer than one filesystem link.

After finding the responsible PID, inspect it before restarting anything:

ps -fp 2450

You can also inspect its file descriptors:

sudo ls -l /proc/2450/fd

Restarting the process or service that owns the deleted file normally closes the open descriptor and releases the disk space. A service reload may or may not close the descriptor, depending on how the application handles its files.

Before restarting anything, identify the process and understand the operational impact.

If deleted files are contributing to a full filesystem, see “Linux Commands to Investigate High Disk Partition Usage“ for a broader disk-usage troubleshooting workflow.

Identifying Resource Users with fuser

The fuser command displays the PIDs of processes using a file, directory, filesystem, or network port. It is more direct than lsof when the immediate objective is to identify what is blocking a resource.

Check Who Is Using a File

Run:

sudo fuser /var/log/myapp/app.log

For more information:

sudo fuser -v /var/log/myapp/app.log

Verbose output includes the username, PID, access type, and command name.

Troubleshoot a Busy Filesystem

A common problem occurs when umount returns:

target is busy

Check the mount point with:

sudo fuser -vm /mnt/data

The -m option treats the target as a mounted filesystem and displays processes accessing resources anywhere under it.

For a second perspective, use:

sudo lsof +f -- /mnt/data

Also confirm that the current shell is not inside the mount point:

pwd

Note: A shell whose working directory is /mnt/data or one of its subdirectories can prevent the filesystem from being unmounted.

Find a Process by Port

To identify the process using TCP port 8080:

sudo fuser -v 8080/tcp

For UDP port 53:

sudo fuser -v 53/udp

Without verbose mode, fuser returns only the PIDs:

sudo fuser 8080/tcp

This output can be captured in a script:

pid=$(sudo fuser 8080/tcp 2>/dev/null)

Before taking action, verify the process:

ps -fp "$pid"

Stop a Process Carefully

fuser can also send signals to processes using a resource. Avoid using fuser -k without specifying a signal as the first troubleshooting action because its default signal is SIGKILL.

sudo fuser -k 8080/tcp

However, immediate termination can interrupt writes, leave temporary files behind, or cause application-level inconsistencies.

A safer approach is to send SIGTERM first:

sudo fuser -k -TERM 8080/tcp

Then verify whether the port was released:

sudo ss -ltnp 'sport = :8080'

Use SIGKILL only when graceful termination fails:

sudo fuser -k -KILL 8080/tcp

Important: Never terminate a process based only on a port number. Confirm whether it belongs to systemd, a container, a user session, or another critical component.

A Realistic Troubleshooting Workflow

Imagine that an application cannot start because port 9000 is already in use.

First, identify the listener:

sudo ss -ltnp 'sport = :9000'

Confirm the result with lsof:

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

Check the process through fuser:

sudo fuser -v 9000/tcp

Assuming the PID is 3127, inspect it:

ps -fp 3127

Display its complete command line:

tr '\0' ' ' < /proc/3127/cmdline
echo

If it is managed by systemd, identify the associated unit:

sudo systemctl status 3127

Restart the service through systemd rather than killing the process manually:

sudo systemctl restart myapp.service

Finally, verify the new listener:

sudo ss -ltnp 'sport = :9000'

This process provides more control than blindly terminating PIDs and makes it easier to understand why the conflict occurred.

Commands Worth Keeping Nearby

List all TCP and UDP listeners:

sudo ss -lntup

Find the owner of TCP port 443:

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

Investigate a busy mount point:

sudo fuser -vm /mnt/data

Find deleted files consuming storage:

sudo lsof +L1

Inspect network connections opened by a process:

sudo lsof -nP -a -p 2450 -i

Monitor socket statistics:

watch -n 2 "ss -s"

Request graceful termination by port:

sudo fuser -k -TERM 8080/tcp

Choosing the Right Tool During an Incident

ss, lsof, and fuser overlap in some areas, but they are most useful when each tool is used for the question it answers best.

Start with ss when the problem involves listening ports, active connections, or TCP states. Use lsof when you need to connect a process to files, sockets, directories, or deleted files that remain open. Use fuser when you need a quick answer about which processes are using a particular file, filesystem, or port.

Identifying a PID should still be treated as the beginning of the investigation rather than permission to terminate the process. Confirm how the process was started, whether it belongs to systemd or another service manager, and what impact a restart or signal may have before taking corrective action.

External References