In the last lesson, when we were running the ping command either on our terminal, as I'm doing so here, or through the exec command inside of our code, when we wanted the command to exit, we were sending the os.interrupt signal, or signal interrupt, either through the cmd.process.signal method inside of our Go code, or by pressing Ctrl + C on the terminal, such as follows. By doing so, it allowed the ping command to exit gracefully, printing out the statistics of its operation before exiting.

This contrasted to when we were just using the kill command of the actual process. Which, if I go ahead and change to, and if we run this code, we should see the command exit after 5 seconds, but we won't receive any of the diagnostics, which you can see here. All we're getting is the command ended goodnight, which is what we were printing after we were waiting for the command to exit.

Instead, the graceful shutdown, which is what happens when we send sigint, is occurring due to the fact that the ping application intercepts the interrupt signal, which notifies the process to shut down, and so it does so performing any final tasks, specifically printing out the ping statistics.

We'll take a look at what graceful shutdown is in the next lesson, however in this lesson we're going to spend some time to better understand signals, what they actually are, and how we can intercept them in our own code, as well as some of the situations why we may want to.

So, first things first, what is a signal? Well, a signal is an asynchronous notification sent to a process or a thread in an operating system to indicate a specific event or condition. Signals can be generated by the operating system, or by other processes, or even the process itself.

If we take a quick look at the Wikipedia page for signals, or signals IPC, which stands for inter-process communication, we can see that it provides a table that lists the POSIX signals, or signals that are specified in the single Unix specification. Some common examples of signals include the sigterm, which is process termination, which is this signal here, termination signal, the sigint, signal interrupt, which we've seen already, which is the terminal interrupt signal, and the sigsegv, which doesn't occur very often in Go, but does occur more in other languages such as C or C++, which stands for Invalid Memory Reference, and usually occurs when a process tries to access memory it's not entitled to do so.

These signals can be delivered at various times throughout the process's life cycle, and can be done so by the operating system in order to communicate system events, such as letting the process know that it's time to shut down, which is the case with signal interrupt. Additionally, signals can also be sent to other processes from one another, in order to perform inter-process communication.

By default, each process has a specified default action when a signal is received, which we can actually view on this table. For instance, the default action for a signal interrupt, or sigint, is to terminate, as well as the same for sigkill, and sigterm, as well as many others. To show the default behaviour of some of these other signals, let's go ahead and start up the ping command again, using ping google.com.

Now we can go ahead and send some other signals to this by using the kill command, which allows us to send a signal to a process. In order to do so however, we first need to obtain the process's ID, which we can do a couple of different ways. The first is to use, say, ps aux, and grep, or ripgrep in my case, for the actual process name. So we could grep for google.com, and we get a list of any processes that have google.com in their arguments. In this case we can see two. The first is our ping command, which is the command on the top of the screen, and the second is the ripgrep command, which is the actual command we're passing in, in order to search for google process.

Therefore in this case the process ID is 2936014. However we can also obtain a process's ID by using another command called pgrep, which is specifically designed for searching for an ID of a process using grep. In this case we can grep for the ping command, and it produces just the PID or process ID that we want. Again 2936014.

By using the pgrep command we can couple it with the kill command in order to send signals to our actual process. For example, if we want to send sigint to our ping command without using Ctrl + C, we can do so by passing in the number 2, which if we take a look at this table you can see correlates to the sigint command as the portable number. Therefore let's go ahead and send in number 2, and we'll use the following syntax to obtain the process ID of pgrep ping as follows. As you can see, signal interrupt was sent and we received the google.com ping statistics.

In addition to sending sigint, if we go ahead and ping again, we can also send other signals by specifying the relevant number. For example, if we specify number 9, this will be sigkill, which will kill the application and in this case cannot be caught or ignored. This signal does basically the same thing as the kill method when it came to our CMD process. So if we go ahead and send it, we shouldn't see the diagnostics be printed out, which is the case. Although we do get some information letting us know that the process was killed.

In addition to sigint and sigkill, another common signal that will often be sent is the sigterm, which is the termination signal. This is very similar to sigint, however it's a little bit more forceful. To send that we can use kill -15 as follows. This time we get the terminated signal rather than the killed signal, although the output is exactly the same.

Therefore the order of precedence between these three is sigint is for interrupting, meaning that a graceful shutdown can take place. The sigterm is terminate pretty much immediately. And sigkill is one that can't be overridden, and is used by the operating system to kill the application outright. In the case of the sigint command, you can see that the default behaviour was overridden. This is achieved by using something called a signal handler, which allows an application or process to override the default behaviour of a signal.

At the lowest level, a signal handler is a function that a process can register to handle a specific signal when it's received. When it comes to Go, in order to register a signal handler, we can use the os/signal package, which provides a few functions in order for us to be able to register specific handlers. The first of these is the ignore function, which will cause any provided signals to be ignored. This means if we wanted to say ignore the os.interrupt signal, we could do so by using this ignore function. However, there are some signals that can't be ignored. For example, sigkill cannot be caught or ignored, so in this case it would still operate.

To show how this works, here I have a really simple example. Here we have a for loop that ranges up to 5, so it iterates 5 times, and in each of those iterations it's performing a time.Sleep, as well as printing some messages so that we can see what's going on. If I go ahead and run this code in a new terminal window, as follows, you should see it print out sleep 5 times, once every second, and then print out the word awake before exiting. If we go ahead and run this again, but this time send a signal interrupt using Ctrl + C, you'll see that it terminates before finishing its tasks.

So let's see what happens if we use the signal.ignore method. First importing the os/signal package, and then calling the ignore function as follows. Then we need to pass in the signal that we want to ignore. In this case, let's go ahead and pass in the os.interrupt signal. Now if I go ahead and run this code again, and if we try to press Ctrl + C, you'll see that nothing happens. To show that this is the case, let's go back to, let's go to another window, and we'll do the same thing again using the go run command, but also let's go ahead and make sure we queue up a kill command so that we can send sigint to it. Let's use pgrep, and we'll grep for signals, which will be the name of the binary.

Now if we go ahead and run this code, and if I go ahead and call sigint again, you'll see nothing happens. However, to prove that signals are going through, if we run this code yet again, and this time we'll do a sig kill, you can see that the signal kill made it through, even though we did manage to sleep for five seconds. So as you can see, if you want to ignore a specific signal, you can do so using the signal ignore.

As we saw in the Wikipedia article about signals, whilst we can ignore the os.interrupt, we can't ignore the kill signal. For example, if we make the following change to use the os.killsignal, and if I go ahead and run this code as follows, now if I try to do kill -9, you'll see it does terminate. In addition to being able to ignore signals, the package also allows us to be able to handle specific actions on them through the use of the notify function. This function, notify, causes package signal to relay incoming signals to C, C being a channel that we pass in with the type of os.signal. Therefore, any incoming signals will be related or written to this channel, which we can then receive on.

If no signals are provided to the function, which is the second parameter, which is a variadic parameter, then all incoming signals will be relayed to C. Otherwise, just the provided signals will. Additionally, there's also some other caveats when it comes to using this function, related to using channels. Basically, you want to make sure you at least have a buffer size of 1 if you're listening to one signal, or many, or increasing that if you're listening to lots of signals. You can also take a look at the example here, which shows how to do this. As you can see, they're creating a channel with a buffer size of 1.

So let's take a look at how we can use the signal.notify function. First things first, let's go ahead and create a new channel of type os.signal as follows. And we'll set the buffer size to 1, as mentioned in the documentation. Next, we can then go ahead and call the signal.notify function, passing in our channel and any signals we want to listen on. Let's, for the meantime, just leave this as nothing. Let's go ahead and get rid of this loop and just leave this as follows. Then we'll do a simple print line saying "waiting for signals" and we can go ahead and then pull the signal off called sig and we'll assign it to be the result of the channel. Then let's go ahead and print out the signal that we actually received, and we'll get rid of the time package because we're no longer using it.

Okay, now if we go ahead and run this code, here you can see we're waiting for signals. And if I press ctrl and c, you can see the interrupt signal comes in. Let's go ahead and actually print some additional lines just so that we can see this was from us. There we go. And let's go ahead and run that again, just so it can be a little bit more clear. Again, pressing ctrl and c, signal received by us, interrupt. Of course, this can also work if we use the kill command. So in this case, if we do kill 2 and then pgrep signals, as we saw before, as you can see, we receive the interrupt signal yet again.

However, this isn't the only signal that will interrupt, as there's a number of other signals we can receive. For example, if I go ahead and close this second terminal window, you'll see we actually received another signal, this time window changed. This is the terminal window size change signal, which if I quickly find, here we go, is at the bottom. This is this signal here, sigwinch, or signal window changed, and is sent to the application when the terminal window size changed. This is very useful for processes that either render a terminal, or say, such as terminal user interfaces, so that they know that the terminal window size changed, and then they themselves can redraw accordingly.

Again, just to hone in on another point, if we go ahead and run this code again, and this time we send up the 9 again, which is the sig kill, you'll notice that we're getting signal killed, but it isn't actually impacting, but it isn't hitting our code. Again, the sig kill is basically a kill switch for any process that cannot be intercepted.

So as you can see, Go makes it very easy for us to define a signal handler through the use of channels, which allows us to have asynchronous communication from other processes or the operating systems, which we can then actually handle. But why would we want to use a handler in the first place? Well, as we saw, in cases such as the sigwinch, or the terminal window size changed, this is very useful for applications that may want to be able to redraw based on the size of the terminal window.

In fact, if you look at my terminal window, I have tmux here, which is always drawing lines at the bottom of the screen. And if I go ahead and change the size of this window using the following command, you can see that the terminal window has changed, and so the tmux command has redrawn the window based on that signal, even though we can't really see that it's happening. But if I go ahead and run this code, and if I go ahead and change this, you can see the window changed event was received by any of the sub processes. And same when I add it back to full screen.

Another common use case for signal handlers is the ability to perform graceful termination, which is something we saw when we looked at the ping command. In this case, when it receives a sig interrupt, it finishes execution and prints out some statistics. Whilst the ping command handles graceful termination in this way, there are many other reasons to do so, such as being able to tidy up any resources that your application might be using, cleaning up any existing files that may have been written to, finishing rights to files that may be in a partial state, or even handling requests as they're in flight.

In fact, graceful termination is such a common operation when it comes to Go that we're going to take a look at how we can achieve it in the next lesson.