Kill a Process on a Port on Mac: Find the PID and Free It

You want port 8080 free. You don’t care what’s using it. You just need it gone. macOS gives you the tools to do this in one Terminal command, once you know the right flags. If you want a full picture of everything listening on your Mac before you decide what to free, see all open ports on your Mac first.

Find the Process First

lsof tells you which process owns a port. The -i flag filters by network socket, and :PORT narrows it to a specific port number:

lsof -i :8080

Sample output:

COMMAND   PID   USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
java     4821  aaron   42u  IPv6 0x...            0t0  TCP *:http-alt (LISTEN)

The PID column is what you need. In this case it’s 4821.

Kill It

kill -9 4821

The -9 flag sends SIGKILL, which forces the process to exit immediately. The process cannot catch or ignore it. The OS terminates it and reclaims the port.

One-Liner: Find and Kill in One Shot

If you just want the port free and don’t need to inspect the process first, you can do both steps at once:

kill -9 $(lsof -ti :8080)

The -t flag tells lsof to output only the PID: no headers, no extra columns. That makes it safe to substitute directly into kill.

SIGTERM vs SIGKILL

The -9 flag is not always the right choice. There are two common signals:

SIGTERM (signal 15): asks the process to exit gracefully. The process can catch this and do cleanup (flush writes, close database connections, save state) before exiting. This is kill 4821 with no flag.
SIGKILL (signal 9): forces the process to exit immediately. No cleanup, no warning. Use kill -9 4821.

For a stuck dev server that’s blocking your port, SIGKILL is fine. For a database or anything writing to disk, try SIGTERM first and give it a few seconds. If it doesn’t exit, then use SIGKILL. Not sure what the process is before you kill it? Identify which app owns the port first.

When the Port Has Multiple Processes

Sometimes lsof returns more than one PID. This happens when a parent process forks worker processes, all sharing the same socket:

COMMAND     PID   USER  FD   TYPE  DEVICE  SIZE/OFF  NODE  NAME
nginx      1100  root   6u  IPv4  ...          0t0   TCP  *:80 (LISTEN)
nginx      1101  aaron  6u  IPv4  ...          0t0   TCP  *:80 (LISTEN)
nginx      1102  aaron  6u  IPv4  ...          0t0   TCP  *:80 (LISTEN)

To kill all of them at once:

kill -9 $(lsof -ti :80)

Because -t outputs each PID on its own line, the shell passes all of them to kill as separate arguments. All three processes get terminated.

Protect Yourself from the Wrong PID

A typo or off-by-one in the port number can kill the wrong process. Before running a kill command on a shared or production system, confirm the process name in lsof output matches what you expect.

If the COMMAND column shows something like postgres, redis-server, or a database daemon, and you were expecting a Node.js dev server, stop and investigate. Killing a database mid-write can corrupt data. Dev servers on common ports like port 3000 already in use often show this pattern when they fork workers.

The macOS Processes That Will Come Straight Back

On a Mac, some ports are held by system services under launchd. Killing those is pointless: launchd relaunches them within seconds, and in a few cases you lose functionality until you log back in.

Port 5000 and 7000 (ControlCenter): AirPlay Receiver, on by default since macOS Monterey. This is the single most common reason a Flask dev server cannot bind port 5000 on a Mac. Do not kill it. Turn it off in System Settings, General, AirDrop and Handoff, AirPlay Receiver, then bind the port normally.
Port 5353 (mDNSResponder): Bonjour. Killing it breaks local network discovery, printer sharing, and AirPlay until launchd restarts it. It always comes back.
Port 631 (cupsd): the printing system. Relaunches on demand the next time anything touches a print queue.
Port 62078 (lockdownd): the iPhone sync listener. Appears whenever a device is paired over USB or Wi-Fi sync.
Port 17500 (Dropbox): LAN sync discovery. Safe to kill, but Dropbox restarts it on next launch.

If lsof shows one of these and you were expecting your own dev server, you are looking at the wrong process. Change your port or disable the service instead of killing it.

Why `kill -9` Sometimes Leaves the Port Busy

Occasionally the process is gone and the port still refuses to bind. Two macOS-specific causes:

The socket is in TIME_WAIT. A closed TCP socket lingers so late packets do not land on a new listener. On macOS that wait is about 30 seconds, not the two minutes usually quoted: the duration is twice the maximum segment lifetime, and macOS ships a 15 second MSL. Linux does not compute TIME_WAIT from an MSL at all, it hardcodes the total wait at 60 seconds (TCP_TIMEWAIT_LEN in the kernel). Check the macOS value with sysctl net.inet.tcp.msl, which reports milliseconds. Confirm the socket state with:

netstat -an | grep 8080

If the state column reads TIME_WAIT, nothing is holding the port and waiting resolves it. A server that sets SO_REUSEADDR can bind straight through it, which is why most dev servers never hit this.

A parent process re-forked a worker. Killing the child frees the port for a moment before the parent spawns a replacement on the same socket. Check for a surviving parent:

ps -o pid,ppid,command -p $(lsof -ti :8080)

If the PPID column points at a process that is not launchd (PID 1), kill the parent instead. Killing children in a loop will never win.

Using Portie

Portie shows every open port on your Mac in a live list, updated every 3 seconds. You can see the process name and PID for each port at a glance. No flags to remember.

The free tier covers local monitoring. The $8.99 one-time unlock adds the ability to kill a process directly from the list with a single click. You choose SIGTERM or SIGKILL from a menu. No Terminal required.