From 868ee6db7057a63e09dc67b7448a6f13efcdddd3 Mon Sep 17 00:00:00 2001
From: Valentin Rothberg <rothberg@redhat.com>
Date: Fri, 31 Jan 2020 14:59:49 +0100
Subject: [PATCH] sigproxy: return after closing the channel

When stopping signal handling (e.g., to properly handle ^C) we are also
closing the signal channel.  We should really return from the go-routine
instead of continuing and risking double-closing the channel which leads
to a panic.

Fixes: #5034
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
---
 pkg/adapter/sigproxy_linux.go | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/pkg/adapter/sigproxy_linux.go b/pkg/adapter/sigproxy_linux.go
index ebfeab7253..35745a6aab 100644
--- a/pkg/adapter/sigproxy_linux.go
+++ b/pkg/adapter/sigproxy_linux.go
@@ -25,11 +25,17 @@ func ProxySignals(ctr *libpod.Container) {
 			}
 
 			if err := ctr.Kill(uint(s.(syscall.Signal))); err != nil {
+				// If the container dies, and we find out here,
+				// we need to forward that one signal to
+				// ourselves so that it is not lost, and then
+				// we terminate the proxy and let the defaults
+				// play out.
 				logrus.Errorf("Error forwarding signal %d to container %s: %v", s, ctr.ID(), err)
 				signal.StopCatch(sigBuffer)
 				if err := syscall.Kill(syscall.Getpid(), s.(syscall.Signal)); err != nil {
 					logrus.Errorf("failed to kill pid %d", syscall.Getpid())
 				}
+				return
 			}
 		}
 	}()
From e6fba1e44898304a0c5560aaecdee53beda1034f Mon Sep 17 00:00:00 2001
From: Brent Baude <bbaude@redhat.com>
Date: Fri, 13 Mar 2020 08:06:19 -0500
Subject: [PATCH] eat signal 23 in signal proxy

due to a change in golang-1.14 and it's changes to make go funcs with tight loops preemptive, signals are now getting "through" that never were before.

From the golang-1.14 announce:

Goroutines are now asynchronously preemptible. As a result, loops without function calls no longer potentially deadlock the scheduler or significantly delay garbage collection. This is supported on all platforms except windows/arm, darwin/arm, js/wasm, and plan9/*.

A consequence of the implementation of preemption is that on Unix systems, including Linux and macOS systems, programs built with Go 1.14 will receive more signals than programs built with earlier releases. This means that programs that use packages like syscall or golang.org/x/sys/unix will see more slow system calls fail with EINTR errors. Those programs will have to handle those errors in some way, most likely looping to try the system call again. For more information about this see man 7 signal for Linux systems or similar documentation for other systems.

Fixes #5483

Signed-off-by: Brent Baude <bbaude@redhat.com>
---
 pkg/adapter/sigproxy_linux.go | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/pkg/adapter/sigproxy_linux.go b/pkg/adapter/sigproxy_linux.go
index 8295e4250a..5695d0e429 100644
--- a/pkg/adapter/sigproxy_linux.go
+++ b/pkg/adapter/sigproxy_linux.go
@@ -20,7 +20,10 @@
 		for s := range sigBuffer {
 			// Ignore SIGCHLD and SIGPIPE - these are mostly likely
 			// intended for the podman command itself.
-			if s == signal.SIGCHLD || s == signal.SIGPIPE {
+			// SIGURG was added because of golang 1.14 and its preemptive changes
+			// causing more signals to "show up".
+			// https://github.com/containers/libpod/issues/5483
+			if s == syscall.SIGCHLD || s == syscall.SIGPIPE || s == syscall.SIGURG {
 				continue
 			}