Find and Kill a Process Using a Port on Linux

Stop getting "address already in use" errors. Find what is holding a port and remove it in seconds.

You start your dev server and get this:

Error: listen EADDRINUSE: address already in use :::3000

Something is already bound to that port. Here is how to find it and get rid of it.

Find the process

Three tools do this job. All are available on any modern Linux system.

ss — fast, always available:

ss -tulnp | grep :3000

tcp   LISTEN  0  128  0.0.0.0:3000  0.0.0.0:*  users:(("node",pid=14221,fd=23))

The PID is in the users column — pid=14221 here.

lsof — more readable output:

lsof -i :3000

COMMAND    PID  USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
node     14221  you   23u  IPv4  91023      0t0  TCP *:3000 (LISTEN)

fuser — bare PID, useful in scripts:

fuser 3000/tcp

Prints just the PID with no extra formatting. Easy to pipe into other commands.

Kill the process

kill 14221

kill sends SIGTERM by default — a polite request to exit. Most processes clean up and die within a second or two.

If the process ignores it:

kill -9 14221

SIGKILL cannot be caught or ignored. The kernel terminates the process immediately, skipping any cleanup. Open files and in-flight writes will not be flushed — use it only when the polite version fails.

Skip the lookup: kill by process name

If you already know what is running:

pkill node

Or target more precisely using the full command line:

pkill -f "node dist/server.js"

Before acting, preview what would match:

pgrep -af node

Same matching logic, no action. Useful when several processes share the same binary name (python, java, node) and you want to target one specific instance.

One-liner for dev environments

kill $(lsof -ti :3000)

lsof -t strips everything except the PID. The subshell feeds it straight into kill. Fine for local development — not something to run blindly in production.

The port is free but still showing as in use

A socket stuck in TIME_WAIT can hold a port for up to 120 seconds after the process exits. This is normal TCP behaviour — the kernel is waiting for any stray packets to clear the network.

Check it:

ss -tnp | grep 3000

If the state is TIME_WAIT and there is no PID in the output, nothing is wrong. Wait a minute and the port clears on its own. If you control the server code and want to eliminate the delay on restarts, set SO_REUSEADDR on the listening socket.