Skip to content

Conversation

@thaJeztah
Copy link
Member

container: rename test file

container: TestReplaceAndAppendEnvVars: assert with gotest.tools

Assert the actual results match the expected one, which should make the
test more complete, and reduces some noise by removing a t.Log.

container: some cleanups in tests

  • use t.TempDir()
  • use t.Name() instead of hard-coding name
  • assert with gotest.tools
  • fix some unhandled errors

container: some cleanups in view tests

  • use t.TempDir() instead of TestMain creating a directory to make
    tests self-contained.
  • fix some unhandled errors, and missing assertions for error-types
  • assert with gotest.tools, but kept the Benchmark tests as-is for now,
    to make sure gotest.tools doesn't impact the results.

container: define defaultStopSignal as a syscall.Signal

"SIGTERM" is defined both for Windows and Linux, so we can define the
signal to use as a syscall.Signal, instead of parsing it from a string
whenever we need to use the default.

container: Container.StopSignal: fix handling of invalid signals

Commit 0e50d94 (#15307) introduced a feature to
allow a custom stop-signal to be set. As part of this, existing code to
parse the signal was extracted to signal.ParseSignal(), which accepts
a string either containing a numeric value or a named signal.

When failing to parse the given signal, it returns an error and a magic
"-1" signal. The changes in 0e50d94 used
the error when creating a container, but for existing container configs,
it would ignore the error and instead check if the signal was "0", in
which case it would fall back to use the default stop-signal (SIGTERM).

Given that signal.ParseSignal() returns "-1" (not "0") for invalid
signals, this would result in the failure going undetected and "-1"
being used instead of the intended default (SIGTERM).

In practice, this issues would unlikely be encountered, as custom signals
are validated when creating the container, but it would be possible for
an image to contain an invalid signal, which would be used by the container
as default.

This patch updates the logic to only use the custom value if no error is
produced and a non-zero, positive signal is returned.

A test-case was added that would fail before this patch:

go test -v -run TestContainerStopSignal
=== RUN   TestContainerStopSignal
    container_test.go:34: assertion failed: signal -1 (s syscall.Signal) != terminated (defaultStopSignal syscall.Signal)
--- FAIL: TestContainerStopSignal (0.00s)

- Human readable description for the release notes

- A picture of a cute animal (not mandatory but encouraged)

Signed-off-by: Sebastiaan van Stijn <[email protected]>
Assert the actual results match the expected one, which should make the
test more complete, and reduces some noise by removing a `t.Log`.

Signed-off-by: Sebastiaan van Stijn <[email protected]>
- use t.TempDir()
- use t.Name() instead of hard-coding name
- assert with gotest.tools
- fix some unhandled errors

Signed-off-by: Sebastiaan van Stijn <[email protected]>
- use t.TempDir() instead of TestMain creating a directory to make
  tests self-contained.
- fix some unhandled errors, and missing assertions for error-types
- assert with gotest.tools, but kept the Benchmark tests as-is for now,
  to make sure gotest.tools doesn't impact the results.

Signed-off-by: Sebastiaan van Stijn <[email protected]>
"SIGTERM" is defined both for Windows and Linux, so we can define the
signal to use as a syscall.Signal, instead of parsing it from a string
whenever we need to use the default.

Signed-off-by: Sebastiaan van Stijn <[email protected]>
Commit 0e50d94 introduced a feature to
allow a custom stop-signal to be set. As part of this, existing code to
parse the signal was extracted to `signal.ParseSignal()`, which accepts
a string either containing a numeric value or a named signal.

When failing to parse the given signal, it returns an error and a magic
"-1" signal. The changes in 0e50d94 used
the error when creating a container, but for existing container configs,
it would ignore the error and instead check if the signal was "0", in
which case it would fall back to use the default stop-signal (SIGTERM).

Given that  `signal.ParseSignal()` returns "-1" (not "0") for invalid
signals, this would result in the failure going undetected and "-1"
being used instead of the intended default (SIGTERM).

In practice, this issues would unlikely be encountered, as custom signals
are validated when creating the container, but it would be possible for
an image to contain an invalid signal, which would be used by the container
as default.

This patch updates the logic to only use the custom value if no error is
produced and a non-zero, positive signal is returned.

A test-case was added that would fail before this patch:

    go test -v -run TestContainerStopSignal
    === RUN   TestContainerStopSignal
        container_test.go:34: assertion failed: signal -1 (s syscall.Signal) != terminated (defaultStopSignal syscall.Signal)
    --- FAIL: TestContainerStopSignal (0.00s)

Signed-off-by: Sebastiaan van Stijn <[email protected]>
@thaJeztah thaJeztah added this to the 28.0.0 milestone Feb 17, 2025
@thaJeztah thaJeztah merged commit 8b2f6fb into moby:master Feb 17, 2025
159 checks passed
@thaJeztah thaJeztah deleted the container_cleanups branch February 17, 2025 10:39
Sign up for free to 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.

2 participants