Find What's Using a Port With Two Commands
If you've ever attempted to bind a process on a port on Linux, BSD, or macOS, only to find that something else is using the port, yet you don't know what that process is, here's a quick way to find the process and remove it.
Recently, when I was using Node Serve to locally deploy the ownCloud documentation, so that I could review some changes I'd made, it couldn't bind to its standard port (5000). I knew that I'd run Node Serve the day before, but thought that the process had been killed. Yet the docs were still rendering, and Node Serve picked port 5001, instead of 5000.
I was sure that I'd killed the process manually, or if not that, when the macOS Terminal process ended, Node Serve would also have exited, so I thought. Unfortunately, that wasn't the case, and there was no way that I was going to restart macOS just to kill a rogue process.
So, here's how I identified and terminated the offending process. Give it a try the next time you're in the same position.
How To Find The Process Bound To a Port
The first thing I did was to use
lsof to identify what process was using TCP port 5000, which is the default for Node Serve.
I did this by running the following command.
lsof -i tcp:5000
lsof is a command that lists open files.
lsof's man file:
An open file may be a regular file, a directory, a block special file, a character special file, an executing text reference, a library, a stream or a network file (Internet socket, NFS file or UNIX domain socket.) A specific file or all the files in a file system may be selected by path.
To break down what the command is doing, it lists the open files (in this case a process) using TCP port 5000. On running the command, the following output was rendered to the console:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME node 10046 settermjd 15u IPv6 0x385f0d85128a038b 0t0 TCP *:commplex-main (LISTEN)
From that output, you can see that one command is listening on TCP port 5000.
In the first column,
COMMAND, you can see that its
node, and in the second column
PID, you can see that it has a process id of
If you're not familiar with process ids, every UNIX/Linux process has one; they're non-negative integers assigned when the process is created.
lsof, I now have the information that I need to kill the process.
However, as I'm the curious type, I just want to find out a bit more about the process.
To do that, I'll use a favourite old command of mine, ps, which show's process status.
As I know the process' id,
10046, I can find out a little more about it by running
ps -p 10046.
This will filter down the list of returned processes, to only that one with process id
Here's the result of running the command.
PID TTY TIME CMD 10046 ttys001 0:00.59 node /usr/local/bin/serve public
You can see that it was started on
ttys001, that it's been running for 59 seconds, and that the full command is
node /usr/local/bin/serve public.
How To Kill a Process
Okay, that's enough further research, now it's time to kill the process.
To do that, we'll use the kill command.
Sure, the name's a bit harsh, but it does the job we need; quickly and efficiently.
kill, I'll pass the signal to send to the process,
9, and the process id, as follows:
kill -9 10046
The process ended quickly, which I confirmed by running
lsof -i tcp:5000 again, which produced no output.
If you're not familiar with UNIX/Linux signals, here's a quick overview:
Signals are a limited form of inter-process communication (IPC), typically used in Unix, Unix-like, and other POSIX-compliant operating systems. A signal is an asynchronous notification sent to a process or to a specific thread within the same process in order to notify it of an event that occurred. Signals originated in 1970s Bell Labs Unix and have been more recently specified in the POSIX standard.
Some of the most commonly used signals are:
Now this is a pretty trivial example of finding and terminating a process. However, if you're stuck for finding what's using a port, and getting rid of it, then give these commands a go, and see how you go. If they don't work properly, or you need some help, let me know in the comments, and I'll see if I can help you out.