Note that github-actions output format is deprecated and no longer supported,
and it is also no longer needed since setup-go problem matcher already
handles default golangci-lint output format ("colored-line-number").
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
If CPU burst knob is non-existent, the current implementation (added in
commit e1584831) still tries to set it again after setting the new CPU
quota, which is useless (and we have to ignore ENOENT again).
Fix this.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Earlier, commit fce8dd4d already increased this timeout from 1 to 5 seconds.
Yet, I just saw this timeout being hit in actuated-arm CI.
Increase the timeout again, this time from 5 to 50 (100 * 0.5) seconds.
Also, use wait_pids_gone, and improve some comments.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
They were failing earlier but are working now.
This includes a fix to criu repo path assignment so it works for actuated case.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
1. A few tests use "criu check --feature" to check for a specific
feature. Let's generalize it.
2. Fix "checkpoint --pre-dump and restore" test to require memory
tracking (which is missing on ARM).
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Since commit c77aaa3f the tail of criu.log is printed by runc, so
there's no need to do the same thing in tests.
Related to 3711, 3816.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
kcmp is often missing: https://man7.org/linux/man-pages/man2/kcmp.2.html
> Before Linux 5.12, this system call is available only if the
> kernel is configured with CONFIG_CHECKPOINT_RESTORE, since the
> original purpose of the system call was for the
> checkpoint/restore in user space (CRIU) feature. (The
> alternative to this system call would have been to expose
> suitable process information via the proc(5) filesystem; this was
> deemed to be unsuitable for security reasons.) Since Linux 5.12,
> this system call is also available if the kernel is configured
> with CONFIG_KCMP.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Commit b6967fa84c moved the functionality of managing cgroup devices
into a separate package, and decoupled libcontainer/cgroups from it.
Yet, some software (e.g. cadvisor) may need to use libcontainer package,
which imports libcontainer/cgroups/devices, thus making it impossible to
use libcontainer without bringing in cgroup/devices dependency.
In fact, we only need to manage devices in runc binary, so move the
import to main.go.
The need to import libct/cg/dev in order to manage devices is already
documented in libcontainer/cgroups, but let's
- update that documentation;
- add a similar note to libcontainer/cgroups/systemd;
- add a note to libct README.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This handles a corner case when joining a container having all
the processes running exclusively on isolated CPU cores to force
the kernel to schedule runc process on the first CPU core within the
cgroups cpuset.
The introduction of the kernel commit
46a87b3851f0d6eb05e6d83d5c5a30df0eca8f76 has affected this deterministic
scheduling behavior by distributing tasks across CPU cores within the
cgroups cpuset. Some intensive real-time application are relying on this
deterministic behavior and use the first CPU core to run a slow thread
while other CPU cores are fully used by real-time threads with SCHED_FIFO
policy. Such applications prevents runc process from joining a container
when the runc process is randomly scheduled on a CPU core owned by a
real-time thread.
Introduces isolated CPU affinity transition OCI runtime annotation
org.opencontainers.runc.exec.isolated-cpu-affinity-transition to restore
the behavior during runc exec.
Fix issue with kernel >= 6.2 not resetting CPU affinity for container processes.
Signed-off-by: Cédric Clerget <cedric.clerget@gmail.com>
The motivation behind this change is to provide a flexible mechanism for
containers within a Kubernetes cluster to opt out of FIPS mode when necessary.
This change enables apps to simulate FIPS mode being enabled or disabled for testing
purposes. Users can control whether apps believe FIPS mode is on or off by manipulating
`/proc/sys/crypto/fips_enabled`.
Signed-off-by: Sohan Kunkerkar <sohank2602@gmail.com>
When we run this:
mount --bind -o remount,diratime,strictatime "$DIR"
It fails in debian testing, when it is the second time we call this
function in the same bats test (i.e. when $DIR is defined already).
strace shows this syscall failing:
mount_setattr(3, "", AT_EMPTY_PATH, {attr_set=MOUNT_ATTR_NOSUID|MOUNT_ATTR_NODEV|MOUNT_ATTR_NOEXEC|MOUNT_ATTR_NOATIME|MOUNT_ATTR_STRICTATIME, attr_clr=MOUNT_ATTR_RDONLY|MOUNT_ATTR_NOATIME|MOUNT_ATTR_STRICTATIME|MOUNT_ATTR_NODIRATIME|0x40, propagation=0 /* MS_??? */, userns_fd=0}, 32) = -1 EINVAL (Invalid argument)
Note it has `MOUNT_ATTR_NOATIME` and `MOUNT_ATTR_STRICTATIME` which
probably causes it to return EINVAL.
This patch simply adds atime to the options, so the mount command now
works and fixes most of the tests in debian testing.
Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
relatime is not shown on some debian systems. Let's check that no other
setting that removes the relatime effect is set, as that should be
enough too.
For more info, see the issue linked in the comments.
Signed-off-by: Rodrigo Campos <rodrigo@sdfg.com.ar>
Prior to this commit, commands like `runc update --cpuset-cpus=1`
were implying to set cpu burst to "0" (which does not mean "leave it as is").
This was failing when the kernel does not support cpu burst:
`openat2 /sys/fs/cgroup/runc-cgroups-integration-test/test-cgroup-22167/cpu.max.burst: no such file or directory`
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
In issue #4210, if we don't provide `--cpu-burst` in `runc update`,
the value of cpu burst will always set to 0.
Signed-off-by: lifubang <lifubang@acmcoder.com>
Aleksa Sarai (5):
VERSION: back to development
VERSION: release v1.2.0-rc.1
changelog: update to include all new changes since 1.1.0
changelog: sync changelog entries up to runc 1.1.12
changelog: mention key breaking changes for mount options
LGTMs: lifubang AkihiroSuda kolyshkin cyphar
Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
[ cyphar: restructuring and removal of outdated or incorrect info ]
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
1. Sort the list of matrix excludes in the order of matrix,
add comments explaining why we disable some jobs.
2. Exclude some jobs:
- runc_nodmz && go 1.20.x
- runc_nodmz && -race
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
We will almost certainly need to eventually rework nsenter to:
1. Figure out a way to make pthread_self() not break after nsenter runs
(probably not possible, because the core issue is likely that we are
ignoring the rules of signal-safety(7)); or
2. Do an other re-exec of /proc/self/exe to execute the Go half of
"runc init" -- after we've done the nsenter setup. This would reset
all of the process state and ensure we have a clean glibc state for
Go, but it would make runc slower...
For now, just block Go 1.22 builds to avoid having broken runcs floating
around until we resolve the issue. It seems possible for musl to also
have an issue, but it appears to work and so for now just block glibc
builds.
Note that this will only block builds for anything that uses nsenter --
so users of our (internal) libcontainer libraries should be fine. Only
users that are starting containers using nsenter to actually start
containers will see the error (which is precisely what we want).
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Kir Kolyshkin