Are deferred functions called when SIGINT is received in Go?

Question

For the snippet below, the deferred call is not made when ^C is received. Is it possible that the cleanup introduces a race condition? If yes, what could be a better pattern of cleanup on receiving an interrupt?

  func fn() {
    // some code
    defer cleanup()
    go func() {
       c := make(chan os.Signal, 1)
       signal.Notify(c, os.Interrupt)

       // Block until a signal is received.
       _ = <-c
       cleanup()
     }
     for {
        // Infinite loop. Returns iff an error is encountered in the 
        // body
     }
}

Shift

Since the accepted answer doesn't really answer the general question of Are deferred functions called when SIGINT is received in Go I think it might be better to re-title this question to something more like: "How do I use defer clauses and signal handlers to cleanup gracefully when I get a SIGINT?" -- I came to this question looking for an answer to the general case of what is supposed to happen where no SIGINT handler is installed, and the accepted answer doesn't help.. – Abeyant

According to this answer, no, "Ctrl-C or another signal will terminate the program without calling deferred functions" – Determined

Answer 1

Note that if you "install" your signal channel with signal.Notify(), the default behavior will be disabled. This means if you do this, the for loop in your fn() function will not be interrupted, it will continue to run.

So when you receive a value on your registered channel, you have to make that for loop terminate so you can do a "clean" cleanup. Else the resources cleanup() ought to free might still be used in for, most likely resulting in error or panic.

Once you do this, you don't even have to call cleanup() manually, because returning from fn() will run the deferred function properly.

Here's an example:

var shutdownCh = make(chan struct{})

func fn() {
    defer cleanup()

    go func() {
        c := make(chan os.Signal, 1)
        signal.Notify(c, os.Interrupt)
        <-c
        close(shutdownCh)
    }()

    for {
        select {
        case <-shutdownCh:
            return
            // Other cases might be listed here..
        default:
        }
        time.Sleep(time.Millisecond)
    }
}

Of course the above example does not guarantee app termination. You should have some code that listens to the shutdownCh and terminates the app. This code should also wait for all goroutines to gracefully finish. For that you may use sync.WaitGroup: add 1 to it when you launch a goroutine that should be waited for on exit, and call WaitGroup.Done() when such a goroutine finishes.

Also since in a real app there might be lots of these, the signal handling should be moved to a "central" place and not done in each place.

Here's a complete example how to do that:

var shutdownCh = make(chan struct{})
var wg = &sync.WaitGroup{}

func main() {
    wg.Add(1)
    go func() {
        defer wg.Done()
        fn()
    }()

    c := make(chan os.Signal, 1)
    signal.Notify(c, os.Interrupt)
    <-c
    close(shutdownCh)
    wg.Wait()
}

func fn() {
    defer cleanup()
    for {
        select {
        case <-shutdownCh:
            return
            // Other cases might be listed here..
        default:
        }
        fmt.Println("working...")
        time.Sleep(time.Second)
    }
}

func cleanup() {
    fmt.Println("cleaning up...")
}

Here's an example output of the above app, when pressing CTRL+C 3 seconds after its start:

working...
working...
working...
^Ccleaning up...

Smetana

This is a good, thorough answer. One improvement you could make on your example work loop is to remove the default case and the time.Sleep() and instead add a new case <-time.After(time.Second): -- this way, the "sleeping" happens inside the select statement instead of after it, and the function can return immediately instead of blocking until the end of the Sleep. (I know this wasn't the main point of the example, but I thought the example would be useful to some readers.) – Abeyant