9c5918
From 868ee6db7057a63e09dc67b7448a6f13efcdddd3 Mon Sep 17 00:00:00 2001
9c5918
From: Valentin Rothberg <rothberg@redhat.com>
9c5918
Date: Fri, 31 Jan 2020 14:59:49 +0100
9c5918
Subject: [PATCH] sigproxy: return after closing the channel
9c5918
9c5918
When stopping signal handling (e.g., to properly handle ^C) we are also
9c5918
closing the signal channel.  We should really return from the go-routine
9c5918
instead of continuing and risking double-closing the channel which leads
9c5918
to a panic.
9c5918
9c5918
Fixes: #5034
9c5918
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
9c5918
---
9c5918
 pkg/adapter/sigproxy_linux.go | 6 ++++++
9c5918
 1 file changed, 6 insertions(+)
9c5918
9c5918
diff --git a/pkg/adapter/sigproxy_linux.go b/pkg/adapter/sigproxy_linux.go
9c5918
index ebfeab7253..35745a6aab 100644
9c5918
--- a/pkg/adapter/sigproxy_linux.go
9c5918
+++ b/pkg/adapter/sigproxy_linux.go
9c5918
@@ -25,11 +25,17 @@ func ProxySignals(ctr *libpod.Container) {
9c5918
 			}
9c5918
 
9c5918
 			if err := ctr.Kill(uint(s.(syscall.Signal))); err != nil {
9c5918
+				// If the container dies, and we find out here,
9c5918
+				// we need to forward that one signal to
9c5918
+				// ourselves so that it is not lost, and then
9c5918
+				// we terminate the proxy and let the defaults
9c5918
+				// play out.
9c5918
 				logrus.Errorf("Error forwarding signal %d to container %s: %v", s, ctr.ID(), err)
9c5918
 				signal.StopCatch(sigBuffer)
9c5918
 				if err := syscall.Kill(syscall.Getpid(), s.(syscall.Signal)); err != nil {
9c5918
 					logrus.Errorf("failed to kill pid %d", syscall.Getpid())
9c5918
 				}
9c5918
+				return
9c5918
 			}
9c5918
 		}
9c5918
 	}()
9c5918
From e6fba1e44898304a0c5560aaecdee53beda1034f Mon Sep 17 00:00:00 2001
9c5918
From: Brent Baude <bbaude@redhat.com>
9c5918
Date: Fri, 13 Mar 2020 08:06:19 -0500
9c5918
Subject: [PATCH] eat signal 23 in signal proxy
9c5918
9c5918
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.
9c5918
9c5918
From the golang-1.14 announce:
9c5918
9c5918
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/*.
9c5918
9c5918
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.
9c5918
9c5918
Fixes #5483
9c5918
9c5918
Signed-off-by: Brent Baude <bbaude@redhat.com>
9c5918
---
9c5918
 pkg/adapter/sigproxy_linux.go | 5 ++++-
9c5918
 1 file changed, 4 insertions(+), 1 deletion(-)
9c5918
9c5918
diff --git a/pkg/adapter/sigproxy_linux.go b/pkg/adapter/sigproxy_linux.go
9c5918
index 8295e4250a..5695d0e429 100644
9c5918
--- a/pkg/adapter/sigproxy_linux.go
9c5918
+++ b/pkg/adapter/sigproxy_linux.go
9c5918
@@ -20,7 +20,10 @@
9c5918
 		for s := range sigBuffer {
9c5918
 			// Ignore SIGCHLD and SIGPIPE - these are mostly likely
9c5918
 			// intended for the podman command itself.
9c5918
-			if s == signal.SIGCHLD || s == signal.SIGPIPE {
9c5918
+			// SIGURG was added because of golang 1.14 and its preemptive changes
9c5918
+			// causing more signals to "show up".
9c5918
+			// https://github.com/containers/libpod/issues/5483
9c5918
+			if s == syscall.SIGCHLD || s == syscall.SIGPIPE || s == syscall.SIGURG {
9c5918
 				continue
9c5918
 			}
9c5918