Skip to content

Ignore SIGURG on Linux. - #2929

Merged
thaJeztah merged 1 commit into
docker:masterfrom
cpuguy83:ignore_sigurg
Jan 16, 2021
Merged

Ignore SIGURG on Linux.#2929
thaJeztah merged 1 commit into
docker:masterfrom
cpuguy83:ignore_sigurg

Conversation

@cpuguy83

@cpuguy83cpuguy83 commented Jan 13, 2021

Copy link
Copy Markdown
Collaborator

In go1.14+, SIGURG is used by the runtime to handle preemtable system
calls.
In practice this signal is caught frequently.

For reference:

https://go.googlesource.com/proposal/+/master/design/24543-non-cooperative-preemption.md
golang/go#37942

@codecov-io

codecov-io commented Jan 13, 2021

Copy link
Copy Markdown

Codecov Report

Merging #2929 (fff164c) into master (9a3fdc1) will increase coverage by 0.06%.
The diff coverage is 78.57%.

@@ Coverage Diff @@## master #2929 +/- ##
==========================================
+ Coverage 57.04% 57.10% +0.06% 
==========================================
Files 297 299 +2 Lines 18655 18665 +10 ==========================================
+ Hits 10641 10658 +17 + Misses 7154 7146 -8 - Partials 860 861 +1 

@silvin-lubeckisilvin-lubecki left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for this PR @cpuguy83 👍 Code looks good, but could we add a unit test on this new behavior ? 🙏

@cpuguy83

Copy link
Copy Markdown
CollaboratorAuthor

I'm not sure we can.

  1. Since it is dealing with signals it is a bit more tricky in general since it is a global resource
  2. Once we upgrade go, it is even more tricky since go used the signal internally.

@silvin-lubecki

Copy link
Copy Markdown
Contributor

I wonder if we can play with the channel returned by the ForwardAllSignals, sending the signal via this way?

ch:=ForwardAllSignals(ctx, fakeCli, "id")
ch<-unix.SIGURG// check fakeCli.ContainerKill was not called

WDYT?

@cpuguy83

Copy link
Copy Markdown
CollaboratorAuthor

I think unless we pass in a <-chan os.Signal (which we won't wire up to the real signals) to ForwardAllSignals we can easily end up with a blocked channel after upgrading go in the test.

@thaJeztah

Copy link
Copy Markdown
Member

Would (some of) these be useful to be included in https://github.com/moby/moby/tree/master/pkg/signal ? Or too unrelated to that package?

@cpuguy83

Copy link
Copy Markdown
CollaboratorAuthor

We could probably add an except ...os.Signal to the CatchAll function.

@cpuguy83

Copy link
Copy Markdown
CollaboratorAuthor

But I really wanted to not modify that package to fix the CLI because dependency hell.

@cpuguy83

Copy link
Copy Markdown
CollaboratorAuthor

Updated this to add a couple of tests.
I did have to refactor ForwardAllSignals to receive a channel instead of returning one.

@silvin-lubeckisilvin-lubecki left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@silvin-lubecki

Copy link
Copy Markdown
Contributor

@cpuguy83 the linter is complaining:

cli/command/container/signals_test.go:38:17: SA1025: it is not possible to use Reset's return value correctly, as there is a race condition between draining the channel and the new timer expiring (staticcheck)
if !timer.Reset(30 * time.Second) {

In go1.14+, SIGURG is used by the runtime to handle preemtable system
calls.
In practice this signal caught *frequently*.
For reference:
https://go.googlesource.com/proposal/+/master/design/24543-non-cooperative-preemption.mdgolang/go#37942
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
@cpuguy83

Copy link
Copy Markdown
CollaboratorAuthor

Fixed lint issue.

Now flakey test?

=== Failed
=== FAIL: cli/command/container TestRemoveForce/without_force (0.00s)
Error: Error: No such container: nosuchcontainer
--- FAIL: TestRemoveForce/without_force (0.00s)
rm_test.go:37: assertion failed: --- removed
+++ →
{[]string}[?->0]:
-: <non-existent>
+: "mycontainer"

@thaJeztah

Copy link
Copy Markdown
Member

ah, interesting; it was reported in #2882 to be flaky; so far don't have a clue yet why (perhaps you can spot the issue?)

@thaJeztah

Copy link
Copy Markdown
Member

kicked CI

@thaJeztahthaJeztah left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@thaJeztah
thaJeztah merged commit 35f023a into docker:masterJan 16, 2021
@thaJeztahthaJeztah added this to the 20.10.3 milestone Jan 21, 2021
@thaJeztahthaJeztah modified the milestones: 20.10.3, 20.10.4Feb 2, 2021
@thaJeztahthaJeztah removed this from the 20.10.4 milestone Feb 4, 2021
@thaJeztahthaJeztah added this to the 21.xx milestone Feb 4, 2021
@cpuguy83
cpuguy83 deleted the ignore_sigurg branch April 27, 2021 19:52
djs55 added a commit to djs55/cli that referenced this pull request May 21, 2021
This extends docker#2929 to Darwin as well as Linux.
Running the example in golang/go#37942
I see lots of:
```
dave@m1 sigurg % uname -ms
Darwin arm64
dave@m1 sigurg % go run main.go
received urgent I/O condition: 2021-05-21 16:03:03.482211 +0100 BST m=+0.014553751
received urgent I/O condition: 2021-05-21 16:03:03.507171 +0100 BST m=+0.039514459
```
Signed-off-by: David Scott <dave@recoil.org>
djs55 added a commit to djs55/cli that referenced this pull request May 21, 2021
This extends docker#2929 to Darwin as well as Linux.
Running the example in golang/go#37942
I see lots of:
```
dave@m1 sigurg % uname -ms
Darwin arm64
dave@m1 sigurg % go run main.go
received urgent I/O condition: 2021-05-21 16:03:03.482211 +0100 BST m=+0.014553751
received urgent I/O condition: 2021-05-21 16:03:03.507171 +0100 BST m=+0.039514459
```
Signed-off-by: David Scott <dave@recoil.org>
djs55 added a commit to djs55/cli that referenced this pull request May 24, 2021
This extends docker#2929 to Darwin as well as Linux.
Running the example in golang/go#37942
I see lots of:
```
dave@m1 sigurg % uname -ms
Darwin arm64
dave@m1 sigurg % go run main.go
received urgent I/O condition: 2021-05-21 16:03:03.482211 +0100 BST m=+0.014553751
received urgent I/O condition: 2021-05-21 16:03:03.507171 +0100 BST m=+0.039514459
```
Signed-off-by: David Scott <dave@recoil.org>
djs55 added a commit to djs55/cli that referenced this pull request May 24, 2021
This extends docker#2929 to Darwin as well as Linux.
Running the example in golang/go#37942
I see lots of:
```
dave@m1 sigurg % uname -ms
Darwin arm64
dave@m1 sigurg % go run main.go
received urgent I/O condition: 2021-05-21 16:03:03.482211 +0100 BST m=+0.014553751
received urgent I/O condition: 2021-05-21 16:03:03.507171 +0100 BST m=+0.039514459
```
Signed-off-by: David Scott <dave@recoil.org>
djs55 added a commit to djs55/cli that referenced this pull request May 24, 2021
This extends docker#2929 to Darwin as well as Linux.
Running the example in golang/go#37942
I see lots of:
```
dave@m1 sigurg % uname -ms
Darwin arm64
dave@m1 sigurg % go run main.go
received urgent I/O condition: 2021-05-21 16:03:03.482211 +0100 BST m=+0.014553751
received urgent I/O condition: 2021-05-21 16:03:03.507171 +0100 BST m=+0.039514459
```
Signed-off-by: David Scott <dave@recoil.org>
thaJeztah pushed a commit to thaJeztah/cli that referenced this pull request May 25, 2021
This extends docker#2929 to Darwin as well as Linux.
Running the example in golang/go#37942
I see lots of:
```
dave@m1 sigurg % uname -ms
Darwin arm64
dave@m1 sigurg % go run main.go
received urgent I/O condition: 2021-05-21 16:03:03.482211 +0100 BST m=+0.014553751
received urgent I/O condition: 2021-05-21 16:03:03.507171 +0100 BST m=+0.039514459
```
Signed-off-by: David Scott <dave@recoil.org>
(cherry picked from commit cedaf44)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants

@cpuguy83@codecov-io@silvin-lubecki@thaJeztah@patrickmscott