[RFC] should we forward SIGURG?

[kolyshkin]

Foreground runc exec and runc run forwards all the signals (that it can) to the process being run.

Since Go 1.14, go runtime uses SIGURG for async preemptive scheduling. This means that runc regularly receives SIGURG and, in case of foreground runc run/exec, it gets forwarded to the container process.

For example:

[kir@kir-rhat runc]$ sudo ./runc --debug exec xx67 sleep 1m
...
DEBU[0000] child process in init()                      
DEBU[0000] setns_init: about to exec    
DEBU[0000]signals.go:102 main.(*signalHandler).forward() sending signal to process urgent I/O condition 
DEBU[0000]signals.go:102 main.(*signalHandler).forward() sending signal to process urgent I/O condition 
DEBU[0000]signals.go:102 main.(*signalHandler).forward() sending signal to process urgent I/O condition 
...

Or, with slightly better debug messages from PR #3363,

DEBU[0000]signals.go:102 main.(*signalHandler).forward() forwarding SIGURG to 819784
DEBU[0000]signals.go:102 main.(*signalHandler).forward() forwarding SIGURG to 819784

The question is -- should we forward SIGURG? Ideally, we should forward signals sent by a user, but ignore the ones generated by go runtime. Alas, there is no way to distinguish.

[thaJeztah]

Yes, this is a tricky one; I know we filter out the signal on the docker CLI when forwarding signals https://github.com/docker/cli/blob/abc8c9b07fb92c2fde03504a33d6327dfde42bfb/cli/command/container/signals.go#L35-L39

I guess the intent is to make runc kill still accept it, so this would only be for the runc exec case?

@kzys @cpuguy83 @tonistiigi any thoughts?

[dqminh]

I think we should ignore it. SIGURG should never be sent to runc process as a non go-generated signal, it is corresponding to TCP URG and runc certainly does not need it.

[kzys]

https://github.com/golang/proposal/blob/master/design/24543-non-cooperative-preemption.md

We use SIGURG because it meets all of these criteria, is extremely unlikely to be used by an application for its "real" meaning (both because out-of-band data is basically unused and because SIGURG doesn't report which socket has the condition, making it pretty useless), and even if it is, the application has to be ready for spurious SIGURG.

Seems it is pretty safe to ignore. That being said, what are the drawbacks of forwarding the signal? Waste of CPU time with no benefits?

[cpuguy83]

Agreed there should not be any reason that people are handling SIGURG from runc because it is being delivered constantly.
As a signal on runc kill is another matter.

ctr and the docker CLI both ignore forwarding this signal.

[kolyshkin]

Looks like the consensus is the signal should be ignored. Opened #3368.

[kolyshkin]

That being said, what are the drawbacks of forwarding the signal? Waste of CPU time with no benefits?

That, plus

• logging some junk in case --debug is set;
• difference between process running on the host and inside a container (the last one gets sporadic SIGURGs, unless -d is used for runc)

[cyphar]

Sorry I was on vacation and only just checked my messages -- is it not possible to disambiguate if SIGURG was sent internally by looking at si_pid?

[kolyshkin]

Sorry I was on vacation and only just checked my messages -- is it not possible to disambiguate if SIGURG was sent internally by looking at si_pid?

In the current implementation (based on signal.Notify) we receive from golang runtime is basically an integer.

There may be a way to use signalfd(2), and it is even wired in x/sys/linux, but I'm not sure if it works well with go runtime.

Alternatively, this could possibly be fixed in Go runtime, so it can filter out signals it sends to itself. I just found there's an open issue about it: golang/go#37942. In there they say something about inability to distinguish between signals generated by runtime itself and those sent by others.

[cyphar]

Ah the point about signal coalescing is a good one, yeah it probably isn't possible to only ignore the Go runtime ones without sometimes missing a real signal from outside the program.