Since the recent release of CRIU has already supported other
arches such as AArch64, ppc64le, and s390x, so we can enable
it now.
Signed-off-by: Dennis Chen <dennis.chen@arm.com>
Upstream-commit: 7fd54a7a48f9f1bb2b28144e38c886d1fe813a04
Component: engine
Use unique names for test resources of container/inspect, container/ps, container/stop tests
Upstream-commit: 57c504799d979caa706142e6f5dc4be4a5b1e3e2
Component: engine
If container will run as non root user, drop permitted, effective caps early
Upstream-commit: b67c1e078c7eeb20199dce301e95fa8999c98109
Component: engine
TestServiceWithPredefinedNetwork test case was failing
at times. To fix the issue, added new API to check
for services after we clean up all services. Tested
multiple times and this sould fix flaky issue.
Signed-off-by: selansen <elango.siva@docker.com>
Upstream-commit: dabffd806c98ab13dbc25e57bee21c5291b9a50c
Component: engine
This moves some of the code that was conditionally
executed on Windows to a separate, windows-only file.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: cd3e84c6b38e74d03ab31db804bc9b49dcab8243
Component: engine
As soon as the initial executable in the container is executed as a non root user,
permitted and effective capabilities are dropped. Drop them earlier than this, so
that they are dropped before executing the file. The main effect of this is that
if `CAP_DAC_OVERRIDE` is set (the default) the user will not be able to execute
files they do not have permission to execute, which previously they could.
The old behaviour was somewhat surprising and the new one is definitely correct,
but it is not in any meaningful way exploitable, and I do not think it is
necessary to backport this fix. It is unlikely to have any negative effects as
almost all executables have world execute permission anyway.
Use the bounding set not the effective set as the canonical set of capabilities, as
effective will now vary.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: 15ff09395c001bcb0f284461abbc404a1d8bab4d
Component: engine
This is a test case for issue https://github.com/moby/moby/issues/35123,
making sure we can set container's memory limit when using
`native.cgroupdriver=systemd`.
[v2: skip if no systemd present]
[v3: add --iptables=false to avoid flaky tests with t.Parallel()]
[v4: rebase after PR#36507 merge]
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: 4ca5c5361059e29ed31074ca5b96f8b2030b5f99
Component: engine
… mainly by skipping if daemon is remote.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: 6016e79d2552b21643f4bfd093ce76d8ef956d79
Component: engine
Commit fd0e24b7189374e0fe7c55b6d26ee916d3ee1655 changed
the stats collection loop to use a `sleep()` instead
of `time.Tick()` in the for-loop.
This change caused a regression in situations where
no stats are being collected, or an error is hit
in the loop (in which case the loop would `continue`,
and the `sleep()` is not hit).
This patch puts the sleep at the start of the loop
to guarantee it's always hit.
This will delay the sampling, which is similar to the
behavior before fd0e24b7189374e0fe7c55b6d26ee916d3ee1655.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 481b8e54b45955e40075f49a9af321afce439320
Component: engine
This PR adds support for compressibility of log file.
I added a new option conpression for the jsonfile log driver,
this option allows the user to specify compression algorithm to
compress the log files. By default, the log files will be
not compressed. At present, only support 'gzip'.
Signed-off-by: Yanqiang Miao <miao.yanqiang@zte.com.cn>
'docker logs' can read from compressed files
Signed-off-by: Yanqiang Miao <miao.yanqiang@zte.com.cn>
Add Metadata to the gzip header, optmize 'readlog'
Signed-off-by: Yanqiang Miao <miao.yanqiang@zte.com.cn>
Upstream-commit: f69f09f44ce9fedbc9d70f11980c1fc8d7f77cec
Component: engine
This test case checks that a container created before start
of the currently running dockerd can be exported (as reported
in #36561). To satisfy this condition, either a pre-existing
container is required, or a daemon restart after container
creation.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: 6e7141c7a2c0de6fa3d6c9dcc56978a81f9d835e
Component: engine
Update libnetwork to 1b91bc94094ecfdae41daa465cc0c8df37dfb3dd to bring in a fix
for stale HNS endpoints on Windows:
When Windows Server 2016 is restarted with the Docker service running, it is
possible for endpoints to be deleted from the libnetwork store without being
deleted from HNS. This does not occur if the Docker service is stopped cleanly
first, or forcibly terminated (since the endpoints still exist in both). This
change works around the issue by removing any stale HNS endpoints for a network
when creating it.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: fb364f07468e94226250a1e77579ee6117c64be2
Component: engine
This updates libnetwork to 8892d7537c67232591f1f3af60587e3e77e61d41 to bring in
IPAM fixes for duplicate IP addresses.
- IPAM tests (libnetwork PR 2104) (no changes in vendored files)
- Fix for Duplicate IP issues (libnetwork PR 2105)
Also bump golang/x/sync to match libnetwork (no code-changes, other
than the README being updated)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 55e0fe24db68b16edccb2fa49c3b1b9d3a9ce58c
Component: engine
connection does. If this isn't done, then a container listening on stdin won't
receive an EOF when the client closes the stream at their end.
Signed-off-by: Jim Minter <jminter@redhat.com>
Upstream-commit: 37983921c90b468cafd3ba2ca2574fb81cafe5a7
Component: engine
Commit 7a7357dae1bccc ("LCOW: Implemented support for docker cp + build")
changed `container.BaseFS` from being a string (that could be empty but
can't lead to nil pointer dereference) to containerfs.ContainerFS,
which could be be `nil` and so nil dereference is at least theoretically
possible, which leads to panic (i.e. engine crashes).
Such a panic can be avoided by carefully analysing the source code in all
the places that dereference a variable, to make the variable can't be nil.
Practically, this analisys are impossible as code is constantly
evolving.
Still, we need to avoid panics and crashes. A good way to do so is to
explicitly check that a variable is non-nil, returning an error
otherwise. Even in case such a check looks absolutely redundant,
further changes to the code might make it useful, and having an
extra check is not a big price to pay to avoid a panic.
This commit adds such checks for all the places where it is not obvious
that container.BaseFS is not nil (which in this case means we do not
call daemon.Mount() a few lines earlier).
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: d6ea46cedaca0098c15843c5254a337d087f5cd6
Component: engine
In case ContainerExport() is called for an unmounted container, it leads
to a daemon panic as container.BaseFS, which is dereferenced here, is
nil.
To fix, do not rely on container.BaseFS; use the one returned from
rwlayer.Mount().
Fixes: 7a7357dae1bccc ("LCOW: Implemented support for docker cp + build")
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: 81f6307eda44ab3a91de6e29304810a976161d74
Component: engine
