How to Use Curl to Check if a Remote Resource is Available
Do you want to check if a file is available on a remote server before attempting to download it - in a short and effective way? If so, and you’re not sure how you’ll learn how in this post.
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.
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.
Quoting 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 10046
.
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.
After running 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 10046
.
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
.
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.
To 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:
1 | HUP (hang up) |
2 | INT (interrupt) |
3 | QUIT (quit) |
6 | ABRT (abort) |
9 | KILL (non-catchable, non-ignorable kill) |
14 | ALRM (alarm clock) |
15 | TERM (software termination signal) |
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.
Do you want to check if a file is available on a remote server before attempting to download it - in a short and effective way? If so, and you’re not sure how you’ll learn how in this post.
The tech sector, if you know what you’re doing, is easier than most fields to get started in. However, you do have to know what you’re doing. In this post, I’m going to step through a series of ways to get started, in case you’re not sure.
There are lots of tips, tricks, and ideas around for hacking your command-line productivity to make you more efficient. However, in this post, I’m not going to show you something that’s super in-depth, ultra-detailed, or talk about an app that you have to install, ctrl+x+e.
Do you want a no-fuss command-line tool to lint the quality of the prose in your technical documentation project, or in your technical writing projects? Do you want something that has an uncomplicated interface, yet provides rich feedback? Then come learn about proselint.
Please consider buying me a coffee. It really helps me to keep producing new tutorials.
Join the discussion
comments powered by Disqus