Fix SIGURG Handling

[tri-adam]

Ignore SIGURG, which is used for non-cooperative goroutine preemption starting with Go 1.14 (more info available here).

Fixes #5231

[cclerget]

I think all engine operation MonitorContainer for singularity/fakeroot/oci engines should also ignore this signal to not send it to container processes

EDIT: simplest is to ignore it in master process https://github.com/sylabs/singularity/blob/c4a0dc2fbcd0793d2b2bab6f23af1e639cdc71ba/internal/app/starter/master_linux.go#L127 with a call to signal.Ignore

[tri-adam]

I think all engine operation MonitorContainer for singularity/fakeroot/oci engines should also ignore this signal to not send it to container processes

Makes sense.

EDIT: simplest is to ignore it in master process

https://github.com/sylabs/singularity/blob/c4a0dc2fbcd0793d2b2bab6f23af1e639cdc71ba/internal/app/starter/master_linux.go#L127

with a call to signal.Ignore

I believe this solution would still leave a small window of time whereby a SIGURG could be queued in the signals chan, between calls to signal.Notify() and signal.Ignore().

To ensure MonitorContainer doesn't pass along SIGURG, two options I can see are:

1. Call signal.Notify() with a specific list of signals to send to signals, which would ensure that signals never receives a SIGURG.
2. Ensure each implementation of (engine.Operations).MonitorContainer() ignores SIGURG.

It's also worth noting that this new SIGURG behaviour also increases the risk that legitimate signals may be dropped. We are using a channel size of one, and according to the documentation, signals are dropped once the channel buffer is filled. Experimentation shows that a busy Go program can generate many SIGURG signals per second, but only queues a single SIGURG at a time in a channel registered with signal.Notify().

In light of all of that, I propose:

• Update signals chan to be of size 2, to account for the likelyhood that SIGURG is queued.
• Ensure each implementation of (engine.Operations).MonitorContainer() ignores SIGURG.

[dtrudg]

LGTM @tri-adam - Am happy that this works, and has the effect of the point @cclerget was making about filtering more generally, but without the potential for a signal to slip through that you brought up.

[tri-adam]

@cclerget can confirm you're good with this as implemented? Will hold off merging until you can weigh in. Thanks!

[cclerget]

@cclerget can confirm you're good with this as implemented? Will hold off merging until you can weigh in. Thanks!

@tri-adam LGTM

It's also worth noting that this new SIGURG behaviour also increases the risk that legitimate signals may be dropped

I still not understand why Go runtime internal didn't handle it internally, they own the signal handler there is siginfo available and they can use sigqueue to pass a specific value to distinguish this signal ...