Listening to OS signals in Golang

No server, application, script or binary stuff is something isolated from the rest of the computer. Being aware of what is happening behind the scenes is useful, because lot of things can happen.

For this reason, Golang offers a simple way to manage this, without any black magic.

Lets suppose we have just a simple main function that starts a simple http server.

package main

func main{
    StartServer()
}

Maybe this works fine, but this is not aware of anything about the underlying OS. This means that, if something signals the main process to stop, this will just stop or crash without the possibility of gracefully shut down the server and it’s child gorutines.

Imagine now that we could pass a a context with cancellation this function as an argument like StartServer(ctx).
Now imagine that we could start a new routine that is aware of any signal of our interest and then cancel this context.

Lets check out the following piece of code and then we will unravel it.

package main

import (
    "context"
    "log"
    "os"
    "os/signal"
)

func listenAndCancel(c chan os.Signal, cancel context.CancelFunc) {
    oscall := <-c
    log.Printf("system call:%+v", oscall)
    cancel()
}

func main(){

    // Making a channel and ctx to comunicate signInt to server
    c := make(chan os.Signal, 1)
    signal.Notify(c, os.Interrupt)
    ctx, cancel := context.WithCancel(context.Background())

    // Spawn a gorutine to cancel root context if signInt occurs
    go listenAndCancel(c, cancel)

    // Starting server with previous context
    StartServer(ctx)

}

First, try to focus on the main function. We start creating a channel with the built in make function. This give us a channel that accepts os.Signals and only can store one of them at a time.

Those signals are a type that Golgang provides in the os package and they represents operative system signals for the runtime.

Then, we have a super useful function: signal.Notify. Intuitively, we can thing that this function is waiting for any os.Interrupt and then pass it through the channel.

If we wanted to look more deep, we can check the documentation:

“Notify causes package signal to relay incoming signals to c. If no signals are provided, all incoming signals will be relayed to c. Otherwise, just the provided signals will.”

So now, we have automated the way in which the runtime listents for interrupt signals, and then pass them to the channel.

Then, we create a context with cancellation. The context will go to StartServer as an argument, where it will be used to give context for any further request or gorutine; and the cancel part will go to the listenAndCancel function used as a gorutine.

What does this last function? Easy: it receives the channel and the cancel, then blocks until an interrupt signal comes out the channel. Then it cancel the context, making the server aware of this OS signaling.