lsof: The Linux Command Every Developer Should Know

Introduction

If you work on Linux systems, sooner or later you’ll run into situations where things just don’t work — your app won’t start, a port is blocked, or something is running in the background and you don’t know what.

One of the most common errors developers see is:

Address already in use

At first, it’s confusing. You didn’t start anything (at least intentionally), so what’s using that port?

This is exactly where the lsof command becomes extremely useful.

Instead of guessing or restarting your system, you can figure out the issue in seconds.

What is lsof?

lsof stands for "List Open Files".

In Linux, everything is treated as a file. That includes:

  • Regular files

  • Directories

  • Network sockets (ports)

  • Pipes

  • Devices

So when you run lsof, you’re basically asking the system:

“Show me which processes are using which files (or ports).”

You can think of it like a more powerful, developer-friendly version of Task Manager — but for files, ports, and processes.

Real-Life Example: Fixing "Address Already in Use"

Let’s say you’re running a backend application on port 4321.

You start your app… and boom:

Address already in use

This usually means another process is already using that port.

Instead of guessing, just run:

lsof -i :4321

You’ll immediately see something like this:

  • Which program is using the port

  • The process ID (PID)

  • The user running it

Once you have the PID, you can stop the process.

kill PID

If the process doesn’t stop (which can happen sometimes), you can force kill it:

kill -9 PID

Use this carefully — it forcefully stops the process, so it won’t get a chance to clean things up.

Hands-on Example with Code Snippets

Let’s walk through a proper example so you can see exactly how this works.

Step 1: Find the process using the port

lsof -i :4321

Sample Output

COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
node     4521 user   23u  IPv4  12345      0t0  TCP *:4321 (LISTEN)

Here, you can clearly see:

  • The process name (node)

  • The PID (4521)

  • The port (4321)

Step 2: Stop the process

kill 4521

Step 3: Force stop (if needed)

kill -9 4521

One-liner Shortcut (Advanced)

If you don’t want to do this step-by-step, you can do everything in one command:

kill -9 $(lsof -t -i :4321)

Basically, it finds the process using that port and kills it in one go.

Quick Tip

If you just want the PID (for scripting or automation), run:

lsof -t -i :4321

Before vs After (Developer Experience)

Before using lsof:

  • Restarting your system again and again

  • Guessing which app is using the port

  • Wasting time debugging blindly

After using lsof:

  • You identify the issue in seconds

  • You target the exact process

  • Your debugging becomes much faster and cleaner

Benefits of Using lsof

  • Works with any tech stack (.NET, Node.js, Python, Java, etc.)

  • Saves a lot of debugging time

  • Helps in low-level system troubleshooting

  • Extremely useful for backend and DevOps work

🧠 lsof Cheat Sheet for Developers

Here are some commands you’ll end up using quite often:

Find process using a specific port:

lsof -i :4321

List all listening ports:

lsof -i -P -n | grep LISTEN

Find TCP ports only:

lsof -i TCP

Find UDP ports:

lsof -i UDP

Find processes by user:

lsof -u username

Find open files by process ID:

lsof -p PID

Kill process:

kill PID

Force kill:

kill -9 PID

Practical Tip

If you work with APIs, microservices, or local servers, you’ll end up using lsof almost daily.

For example:

  • Running multiple .NET APIs locally

  • Debugging port conflicts in Node.js apps

  • Working with Docker containers

Whenever something feels "stuck" or "already in use", lsof is usually the fastest way to understand what’s going on.

🎯 Must-Remember Command

lsof -i :PORT

If you remember just this one command, you’ll be able to solve most port-related issues without any frustration.

Conclusion

lsof is one of those small commands that makes a huge difference in your daily development workflow.

It removes guesswork, gives you visibility into what’s happening inside your system, and helps you debug issues quickly.

Once you start using it regularly, it becomes second nature — and you’ll rarely feel stuck when dealing with port or process-related problems.