Some linters were complaining about the testing.T not being used; put
it to use to silence the linter.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These comments were added to enforce using the correct import path for
our packages ("github.com/docker/docker", not "github.com/moby/moby").
However, when working in go module mode (not GOPATH / vendor), they have
no effect, so their impact is limited.
Remove these imports in preparation of migrating our code to become an
actual go module.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
container.HealthStatus is a pseudo-type (alias for string) that was
introduced in 1e4bb14bcd.
Changing this field to use that type as a potential stepping-stone
towards making that type a distinct type.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
State.RemovalInProgress was originally non-exported when it was added in
[40945fc186][1], adding a comment that the
field should not be persisted to disk.
But when moved to a separate package in [6bb0d1816a][2],
it was was exported, without adding `json:"-"`. As a result, it's now persisted
to disk;
cat /var/lib/docker/containers/e493924a99cad918cda8048f967032729105ee072d563d734125cec46e1b5885/config.v2.json | jq .State
{
"Running": true,
"Paused": false,
"Restarting": false,
"OOMKilled": false,
"RemovalInProgress": false,
"Dead": false,
"Pid": 5053,
"ExitCode": 0,
"Error": "",
"StartedAt": "2025-05-13T12:12:15.115512564Z",
"FinishedAt": "0001-01-01T00:00:00Z",
"Health": null
}
Note that this type is used internally, and (while similar) is not used for
API responses;
docker inspect e493924a99cad918cda8048f967032729105ee072d563d734125cec46e1b5885 | jq .[].State
{
"Status": "running",
"Running": true,
"Paused": false,
"Restarting": false,
"OOMKilled": false,
"Dead": false,
"Pid": 5053,
"ExitCode": 0,
"Error": "",
"StartedAt": "2025-05-13T12:12:15.115512564Z",
"FinishedAt": "0001-01-01T00:00:00Z"
}
However, interestingly, [`daemon.restore`][3] does take this field into account
while restoring containers, which seems that it depends on the field being
persisted to disk. That logic was added in [ce72473197][4].
That logic may be redundant if we no longer persist to disk, as the `State.Dead`
is already set when cleaning up a container in [`daemon.cleanupContainer`][5].
[1]: 40945fc186
[2]: 6bb0d1816a (diff-60173e67d15f3085dd09956b3ffa83566ae25fec61cfe08ddd2e1c37223e3be7R24)
[3]: d42d79dceb/daemon/daemon.go (L498-L514)
[4]: ce72473197
[5]: 294f0c36e4/daemon/delete.go (L124-L126)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Makes the code slightly more idiomatic. These paths avoided uses of
defer because they came with an overhead in older versions of Go,
but this overhead should now be neglectible.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The container.WaitCondition type was deprecated in
100102108b, but this use of the
deprecated alias was left behind.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Introduce a ValidateHealthStatus utility in api/types/container to
validate if a given HealthState is valid.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Alias and deprecate the status types and constants from the root
container package. The root container package is intended for use
within the daemon and no the api package.
Signed-off-by: Derek McGowan <derek@mcg.dev>
Go maintainers started to unconditionally update the minimum go version
for golang.org/x/ dependencies to go1.23, which means that we'll no longer
be able to support any version below that when updating those dependencies;
> all: upgrade go directive to at least 1.23.0 [generated]
>
> By now Go 1.24.0 has been released, and Go 1.22 is no longer supported
> per the Go Release Policy (https://go.dev/doc/devel/release#policy).
>
> For golang/go#69095.
This updates our minimum version to go1.23, as we won't be able to maintain
compatibility with older versions because of the above.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This fixes unnecessary errors being written to the daemon log after
copying container streams failed due the streams being closed explicitly:
time="2025-03-06T13:20:53.473232423Z" level=error msg="copy stream failed" error="io: read/write on closed pipe" stream=stdin
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Remove output variables, and use explicit returns
container/stream/bytespipe/bytespipe.go:165:2: naked return in func `Read` with 37 lines of code (nakedret)
return
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
While going through some logs from CI, I noticed this log-entry on Windows,
produced as part of a test;
2025-02-25T03:23:17.6584227Z [Error] Handler for POST /v1.48/containers/b47b1e632188426d6d42a4be04f9a3cc1eca40cfed9536d277011052af0b04f5/update returned error: Cannot update container b47b1e632188426d6d42a4be04f9a3cc1eca40cfed9536d277011052af0b04f5: Restart policy cannot be updated because AutoRemove is enabled for the container
While updating is an error for the user, it's not an error in the daemon,
so we should return the correct error-type (and avoid logging it as an
error in daemon logs).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 0e50d946a2 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 0e50d946a2 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 <github@gone.nl>
"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 <github@gone.nl>
- 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 <github@gone.nl>
- 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 <github@gone.nl>
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 <github@gone.nl>
Adding a `default` statement, and not an explicit "WaitConditionNextExit",
so that disabling the "default-signifies-exhaustive" linter option will
make it show up.
container/state.go:237:2: missing cases in switch of type container.WaitCondition: container.WaitConditionNextExit (exhaustive)
switch condition {
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This makes `WritableCgroups` a pointer so we can error when it's specified in invalid configurations (both rootless and user namespaces).
Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
Fixes#42040Closes#42043
Rather than making cgroups read-write by default, instead have a flag
for making it possible.
Since these security options are passed through the cli to daemon API,
no changes are needed to docker-cli.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
