container: Container.StopSignal: fix handling of invalid signals and cleanup tests #49471
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
container: some cleanups in view tests
tests self-contained.
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 acceptsa 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 invalidsignals, 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:
- Human readable description for the release notes
- A picture of a cute animal (not mandatory but encouraged)