• Servers and Tools

Sending Signals

From the class:  Processes

So far we've been running processes directly in the Bash console, and if we close the Bash console, if we close this terminal window up here, then the process will be killed because the parent process will have been killed. But we can actually detach this process so that it runs even though this top-level process gets killed. And the way we can do that is let's hit Control C to get out of this process.

I can see Node.js and then the file that I want to run. And I'll use an ampersand at the end, and that will tell Bash that I want this to run in the background. So I can press Enter one more time, and notice that it prints out the PID, or the Process ID, that was created when this process was created in the background. And if we go down to the bottom now and say ps af again, we should see that right now the Node.js program is still a child of Bash.

But let's try canceling out or closing the top window. And now what I'm going to do is use a ps, but with a few more options, because I want to see all the different processes that are on the system. And I just remember it as ajxf. So that's going to show us all the processes.

And notice our Node.js program is down there at the bottom. It still has its same process ID of 8852, but now its parent ID is 1. So you notice that it doesn't have any hierarchy here. It's just a child of the process ID of 1.

This process ID of 1, it's got a special name. It's called the Root process. It's the first process that gets created. And any child or any process that gets created on the system that doesn't have a parent is automatically attached to this Root process. So even though we've closed the other terminal window, our program is still running. And if want to be sure you, could use curl again to send it another HTTP request.

So we can see it's still running here. Now, normally when you're running a server, you don't start programs the way that we just did using that ampersand. That's not really the best way to run programs in the background, because there's nothing monitoring this process right now, and if anything happened, it wouldn't be restarted. And if we restart the machine, if we reboot the machine, the process won't start automatically. But I wanted to show you a quick and dirty way that you can get a process running in the background and that it's still running and attached to the Root process with a process ID of 1.

Now, what if we want to stop this process? How can we actually communicate with it from a different shell? Well, the operating system gives us the ability to send something called a signal to any running process. And a signal you can think of as like a message that gets sent and delivered to the process on our behalf. And the process can decide what it wants to do with the signal, and there's a whole bunch of different signals that we can send.

The command that you can use to send a signal is called Kill, which is a little bit of a strange sounding command because the default signal that gets sent tells the process to kill itself or to just stop. But it's actually used-- this command kill is used to send any kind of signal to a running process. And we normally type "kill" and then the process ID of the process that we want to send its signal to.

If you want to learn about all the different types of signals, you can use the -l option. And here we have a whole list of them. And the default signal that's going to get sent is this SIGTERM signal, which tells the process to just die. But as you can see, there's a lot more signals here that can be sent, and they become really useful for things like if you have a server running, you can send a signal to a running server that tells it to reload a configuration file or too hot reload without actually shutting down the process. And so there's a bunch of different uses for these signals.

So let's go ahead and try to send a SIGTERM signal to this running process with a process ID of 8852. So we can type kill, and then -s and then the name of the signal or the number of the signal. So I could say SIGTERM and then we'll send it to 8852. Now, because this is the default, I don't actually need to do this. I could just say kill 8852. And now if we use PS ajxf again, notice that the process is gone. So there's no more process down here with that PID because we've destroyed it using the kill command.

Let's go ahead and start up that program again, because I'm going to show you a slightly easier way that we can accomplish that use case of killing a running process. So I'll take Node.js HTTP server. We'll get it running again in the background. And just press Enter. So now we've got a PID of 9057.

And if I want to not remember that PID number, I just want to kill any process that has been run with Node.js, what I can do is use the pkill command. And the pkill command lets us send a signal to a process by name. So I can say pkill Node.js, and that will have the same effect as using kill with the Process ID of 9057.

Let's just double check. We'll say ps ajxf. Just kind of memorize it. That's the one I use the most. And sure enough, that process has been successfully killed.

So signals are just a way for us to communicate with a running process without actually having to run any code. We can just ask the operating system to send a message on our behalf using the kill command.