Migrate test api images search json content type from integration cli to integration tests
Signed-off-by: Abubacarr Ceesay <abubacarr671@gmail.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- update the Dockerfile to switch to the cli-variant (as it doesn't
require a docker daemon), and update to the latest v29 image
- update the script to not use the deprecated libnetwork repository
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The minInt() helper function was introduced before Go had a built-in
min() function. Since the module requires Go 1.25 (and the built-in
min/max were introduced in Go 1.21), minInt() is now redundant.
Replace the one call site with the built-in min() and remove the
helper function.
Signed-off-by: Pham Duc Nam <nam8dmd@gmail.com>
Move the useful Mounts API create coverage out of integration-cli and
into the container integration tests that own the behavior.
Add volume mount inspect assertions to TestContainerVolumeAnonymous for
destination normalization, read-only named volumes, explicit driver
configuration, and NoCopy mounts.
Add a focused bind mount inspect test for read-only bind mounts and
shared propagation.
Do not port the full integration-cli matrix. Existing integration tests
already cover anonymous volume creation and labeling, anonymous volume
removal with RemoveVolumes, and generic bind propagation handling.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
As libnftables uses `select(2)` on the netlink socket the process is
aborted if the socket's file descriptor is >= 1024. A dockerd process
could easily exceed 1024 open file descriptors at a time under normal
circumstances, so there is a risk of libnftables killing dockerd at a
random time through no fault of dockerd. Default to programming nftables
rulesets by exec'ing `nft -f` until libnftables is updated to be
compatible with processes that open a large number of file descriptors
by using `poll(2)` or `epoll(2)` instead of `select(2)`.
Signed-off-by: Cory Snider <csnider@mirantis.com>
Try to deflake:
- TestStopContainerWithTimeoutCancel
- TestContainerRestartWithCancelledRequest
- TestWaitBlocked
- TestWaitRestartedContainer
Several container integration tests rely on shell TERM traps to produce
specific stop, restart, or wait behavior.
They issue stop or restart requests immediately after container
creation, so dockerd can signal the process before the shell installs
its trap.
When that happens, the process uses default signal behavior and tests
can miss the expected log line or observe the wrong exit status.
Emit a readiness log after installing each trap and wait for it before
issuing stop or restart. Move logsContains into a shared helper so the
readiness check can be reused by the affected tests.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Replace flaky legacy CLI restart-policy tests with container API
integration coverage.
The CLI tests poll inspect output after short-lived detached containers
exit, which can observe transient daemon monitor state while cleanup or
restart-policy handling is still settling.
On Windows this can race a manual restart against an `on-failure:3`
container that has not exhausted its automatic retries.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This is the sixth patch release of the 1.3.z series of runc. Among some
performance improvements and bugfixes, it includes a fix for a low-severity
vulnerability ([CVE-2026-41579]) and users are encouraged to update. As it was
a low-severity vulnerability and it was reported by multiple people, we decided
to release it publicly with NO EMBARGO.
Security
This release includes a fix for the following low-severity security issue:
- CVE-2026-41579 allowed a malicious image with a /dev symlink to have
limited write access to the host filesystem in ways that our analysis
indicates was too limited to be problematic in practice. This bug was very
similar to those fixed in CVE-2025-31133, CVE-2025-52565, CVE-2025-31133
and was simply missed at the time when we hardened the rootfs preparation
code. We have conducted a deeper audit and not found any other problematic
cases.
Fixed
- A regression in runc v1.3.0 which can result in a stuck runc exec or
runc run when the container process runs for a short time.
- Various integration test improvements.
Changed
- When masking directories with maskPaths, runc will now re-use a single
tmpfs instance (which is not writable) to reduce the number tmpfs
superblocks that need to be reaped when containers die (in particular,
Kubernetes applies masks to per-CPU sysfs directories which get expensive
quickly).
[CVE-2026-41579]: https://github.com/opencontainers/runc/security/advisories/GHSA-xjvp-4fhw-gc47
full diff: https://github.com/opencontainers/runc/compare/v1.3.5...v1.3.6
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Concurrent bulkSyncNode calls targeting the same node overwrite each
other's entry in bulkSyncAckTbl. Only the last channel gets closed by
handleBulkSync; the rest block for 30s on a channel nobody will ever
close. This causes unnecessary delays for DNS resolution on newly
joined swarm nodes.
Only have unsolicited bulk syncs subscribe to be notified when the peer
replies with its own bulk sync as only unsolicited bulk syncs solicit a
reply. Correlate the reply to its soliciting bulk-sync using Lamport
timestamps.
Co-authored-by: Dustin Kaiser <8209087+mrnicegyu11@users.noreply.github.com>
Signed-off-by: Cory Snider <csnider@mirantis.com>
These were the only two jobs running directly via `runs-on:` that did
not have a `timeout-minutes` guardrail. Add 120 minutes as a starting
point to prevent runaway jobs, matching the existing convention used
elsewhere in the workflows. Tuning each job's timeout to its usual
runtime is left as a follow-up, as suggested in the issue.
Signed-off-by: Takumi Akasaka <takumiakasaka1231@gmail.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
ContainerUpdate only starts applying per-device blkio settings in the
current API version.
The fields existed in the Go request type before that because it shares
`container.Resources` with other endpoints, but they were not documented
as supported for container update and older daemons ignored them.
Clear these fields when handling requests for older API versions so
clients pinned to those versions keep the previous behavior, while v1.55
clients can use the newly supported fields.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
