The runsc job runs on ubuntu-latest, which is moving to Ubuntu 26.04,
whose sudo (sudo-rs) does not support -E ("preserving the entire
environment is not supported, '-E' is ignored"). critest.sh then fails
on the unset TEST_RUNTIME, the only variable the step did not pass
explicitly.
Pass it on the sudo command line with the others and drop -E.
Signed-off-by: Maksym Pavlenko <pavlenko.maksym@gmail.com>
The `urfave_cli_no_docs` build tag was removed in urfave/cli v3, with doc
generation moved to a separate module.
Remove the obsolete tag and the special handling for gen-manpages, which is
no longer needed after the migration to v3.
updates f72829f36b.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Add the `grpcnotrace` build tag to exclude gRPC's legacy tracing integration
and reduce binary sizes.
This reduces the size of containerd by ~272 KiB, containerd-stress by ~448 KiB,
and ctr by ~512 KiB, saving ~1.2 MiB overall.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The test tarball from test/build.sh is built on the kubekins image and
run on other distros. A dynamic runc built on Debian trixie needs
GLIBC_2.38 and fails on AL2023 (kubernetes/kubernetes#142987).
Build with `make static` like the runc release binaries. EL has no
libseccomp-static, so the Fedora/EL VMs keep the dynamic build via
RUNC_DYNAMIC=1.
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
Only the Windows listener and dialer take the unix:// scheme.
Assisted-by: OpenCode (claude-sonnet-5-5)
Signed-off-by: Eric Curtin <eric.curtin@docker.com>
This release includes 1 security fix following the security policy:
- crypto/x509: mitigation for security concerns with a specific Certificate Authority
We're blocking trust in a small set of intermediate certificates due to specific security concerns around their operation.
Verify will now filter out chains which contain these intermediates, preventing them from being returned to the caller.
We highly recommend immediately upgrading to this release.
This is CVE-2026-111943 and Go issue https://go.dev/issue/82345.
release notes: https://go.dev/doc/devel/release#go1.27.3
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This change updates Microsoft/hcsshim to v0.15.0 and Microsoft/go-winio
to v0.6.4.
This moves containerd back to mainline and off of the internally tagged
release candidate versions.
Signed-off-by: Justin Terry <terryjustin@microsoft.com>
TestShutdownAfterCloseLeavesAReusedFdAlone writes a line into a pty and expects one read on the receiving FIFO to return "still here\r\n". With output post-processing on, the line discipline writes the bytes before the newline and the CR LF it translates the newline into as two separate writes, and the copier forwards each as it arrives, so a single read can return the first part alone. CI hit this on four matrix entries across three pull requests on the day the test merged.
Read the full expected line with io.ReadFull instead. A missing delivery still fails through the five second timeout.
Signed-off-by: Maksym Pavlenko <pavlenko.maksym@gmail.com>
Init.Delete takes p.mu and holds it across initState.Delete, whose
delete() shuts the terminal console down and waits up to 10s for stdio
to drain, execs `runc delete`, closes the process IO and console and
unmounts the rootfs. Init.Status, ExitStatus and
ExitedAt take the same mutex, so the shim's task.State RPC, which calls
all three, queues behind a Delete. containerd gives State a 2s deadline
(io.containerd.timeout.task.state), so the call fails. Depending on the
containerd version that is logged as "get state for <id>: context
deadline exceeded" and the task reported as UNKNOWN, or the error is
propagated, making Get fail and List drop the task. execProcess has the
identical shape with e.mu.
This is easy to hit when the unmount is slow. On a node with tens of GB
of dirty page cache, umount of the overlayfs rootfs calls
sync_filesystem() on the upper filesystem and was measured at 17.6s with
12.9 GB dirty (0.22s with 1.0 GB). That node logged 4,661 State timeouts
across 284 containers over a window of heavy writes.
This change lets State answer while Delete runs. Delete now releases mu
for the slow cleanup, and every method that is not a plain reader still
waits for the cleanup to end:
- Init and execProcess get a `deleting` channel, read and written only
with mu held. delete() is entered and left with mu held; it sets
`deleting`, unlocks, runs the old body unchanged, and a deferred
relock clears `deleting` and closes the channel, whether the cleanup
succeeded, failed or panicked.
- A new lock() takes mu and, while `deleting` is set, unlocks, waits for
the channel and locks again. Every method that
changes the process (Init and exec alike) now calls lock() instead of
mu.Lock(), so the cleanup is still exclusive with all of them, exactly
as when Delete held mu throughout. They then run
against deletedState if Delete succeeded, or the previous state if it
failed, which is what they saw before.
- Status, ExitStatus and ExitedAt keep taking mu directly and so no
longer wait for the cleanup. They report the state from before the
Delete, since nothing is changed until it ends: a created process
stays created with a zero exit status and exit time, and a stopped
one keeps its real exit status and exit time. There is no
created -> stopped -> created flicker if the Delete fails.
The state machine (init_state.go, exec_state.go, deleted_state.go) is
unchanged, and there is no second lock: readers still take mu, so Status
during an in-flight `runc start` still waits and returns "running",
which CRI recovery relies on (a task seen as created is killed).
Behavior change: State/Status/ExitStatus/ExitedAt no longer wait for the
cleanup part of Delete and report the state from before the Delete. If
the Delete fails nothing changes, and an exit that arrived meanwhile is
applied afterwards, as it was on main. One consequence: while the
Delete of a created task with a non-zero pid runs, a second plain
task.Delete from the client (no WithProcessKill) sees "created" and
fails at once with "task must be stopped before deletion", where it
used to wait for the first Delete, see "stopped" and get NotFound.
Everything else is unchanged: other calls wait for Delete as before, a
second Delete waits and gets NotFound, exit events wait, and the task
service still removes the process only after Delete returns.
Because mu is now released inside delete(), any new method that changes
a process must take mu through lock(); this is documented on mu.
This does not make Delete faster. It still takes as long as before, and
the dirty page cache that makes umount slow is a separate problem.
Timeouts are unchanged.
Tests: Delete is blocked inside an io.Closer; State must return and
report the pre-Delete state, mutating methods must wait, and readers
must take mu.
Assisted-by: Claude Code (Claude Sonnet 5.5)
Signed-off-by: Md Tahsin Rahman <tahsin8243@gmail.com>
pullProgressReporter samples activeReqs and totalBytesRead on a periodic
ticker. A response with an empty body, such as a manifest Resolve HEAD
request, does not increment totalBytesRead. In addition, an activeReqs
transition to zero and back to one between ticker ticks is not observed
by the ticker. In both cases, lastSeenTimestamp is not updated and a
subsequent request can be cancelled before it has run for timeout.
Record the timestamp of the most recent request start, response header
receipt, or body byte read in pullRequestReporter, and advance
lastSeenTimestamp from that timestamp on each tick.
Assisted-by: Antigravity
Signed-off-by: Samuel Karp <samuelkarp@google.com>
Maksym Pavlenko