Burstable CFS controller is introduced in Linux 5.14. This helps with
parallel workloads that might be bursty. They can get throttled even
when their average utilization is under quota. And they may be latency
sensitive at the same time so that throttling them is undesired.
This feature borrows time now against the future underrun, at the cost
of increased interference against the other system users, by introducing
cfs_burst_us into CFS bandwidth control to enact the cap on unused
bandwidth accumulation, which will then used additionally for burst.
The patch adds the support/control for CFS bandwidth burst.
runtime-spec: https://github.com/opencontainers/runtime-spec/pull/1120
Co-authored-by: Akihiro Suda <suda.kyoto@gmail.com>
Co-authored-by: Nadeshiko Manju <me@manjusaka.me>
Signed-off-by: Kailun Qin <kailun.qin@intel.com>
As of previous commit, this is implied in a particular scenario. In
fact, this is the one and only scenario that justifies the use of -a.
Drop the option from the documentation. For backward compatibility, do
recognize it, and retain the feature of ignoring the "container is
stopped" error when set.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
By default, the container has its own PID namespace, and killing (with
SIGKILL) its init process from the parent PID namespace also kills all
the other processes.
Obviously, it does not work that way when the container is sharing its
PID namespace with the host or another container, since init is no
longer special (it's not PID 1). In this case, killing container's init
will result in a bunch of other processes left running (and thus the
inability to remove the cgroup).
The solution to the above problem is killing all the container
processes, not just init.
The problem with the current implementation is, the killing logic is
implemented in libcontainer's initProcess.wait, and thus only available
to libcontainer users, but not the runc kill command (which uses
nonChildProcess.kill and does not use wait at all). So, some workarounds
exist:
- func destroy(c *Container) calls signalAllProcesses;
- runc kill implements -a flag.
This code became very tangled over time. Let's simplify things by moving
the killing all processes from initProcess.wait to container.Signal,
and documents the new behavior.
In essence, this also makes `runc kill` to automatically kill all container
processes when the container does not have its own PID namespace.
Document that as well.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
1. Fix some missing punctuation, use proper case.
2. Remove "runc init" (previously removed from "runc --help" by commit
7a0302f0d7).
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
- add the new mode and document it;
- slightly improve the --help output;
- slightly simplify the parsing code.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Now the only remaining file that needs shellcheck warnings to be fixed
is bash-completion. Note that in Makefile's TODO.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This was introduced in an initial commit, back in the day when criu was
a highly experimental thing. Today it's not; most users who need it have
it packaged by their distro vendor.
The usual way to run a binary is to look it up in directories listed in
$PATH. This is flexible enough and allows for multiple scenarios (custom
binaries, extra binaries, etc.). This is the way criu should be run.
Make --criu a hidden option (thus removing it from help). Remove the
option from man pages, integration tests, etc. Remove all traces of
CriuPath from data structures.
Add a warning that --criu is ignored and will be removed.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Currently, if a container is paused (i.e. its cgroup is frozen), runc exec
just hangs, and it is not obvious why.
Refuse to exec in a paused container. Add a test case.
In case runc exec in a paused container is a legit use case,
add --ignore-paused option to override the check. Document it,
add a test case.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
In some setups, multiple cgroups are used inside a container,
and sometime there is a need to execute a process in a particular
sub-cgroup (in case of cgroup v1, for a particular controller).
This is what this commit implements.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Wire through CRIU's support to change the mount context on restore.
This is especially useful if restoring a container in a different pod.
Single container restore uses the same SELinux process label and
same mount context as during checkpointing. If a container is being
restored into an existing pod the process label and the mount context
needs to be changed to the context of the pod.
Changing process label on restore is already supported by runc. This
patch adds the possibility to change the mount context.
Signed-off-by: Adrian Reber <areber@redhat.com>
Currently there's no way to distinguish between the two cases:
- runc exec failed;
- the command executed returned 1.
This was possible before commit 8477638aab, as runc exec exited with
the code of 255 if exec itself has failed. The code of 255 is the same
convention as used by e.g. ssh.
Re-introduce the feature, document it, and add some tests so it won't be
broken again.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Current runc man pages are ugly (no proper man page formatting)
and very short (mostly just a copy-paste from the "runc <command>
--help" output. They are also somewhat obsoleted as not all CLI updates
were propagated to man/*.
This commits makes the first step to solving this.
In short:
- added some more information about some options;
- lots of formatting fixes;
- use references to other man pages and web pages;
- fix SYNOPSYS (formatting, mostly);
- removed the repeated description of <container_id> from every page;
- added SEE ALSO;
- something else I forgot.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Restoring an SELinux enabled container with Podman will result in
a container with the exactly same SELinux process labels as during
checkpointing. CRIU takes care of all the process labels.
Restoring multiple copies of a checkpointed container will result in all
containers having the same SELinux process labels, which might be
undesired.
When looking at Pods all container in a Pod share the process label
of the infrastructure container. To restore a container into and
existing Pod it is necessary to tell CRIU to restore the container
with the infrastructure container process label.
CRIU supports setting different process labels using --lsm-profile for a
long time and this just passes the process label information from runc
to CRIU.
Unfortunately CRIU has a bug as no one was using the --lsm-profile
option so this changes requires the upcoming CRIU version 3.16.
Signed-off-by: Adrian Reber <areber@redhat.com>
This is somewhat radical approach to deal with kernel memory.
Per-cgroup kernel memory limiting was always problematic. A few
examples:
- older kernels had bugs and were even oopsing sometimes (best example
is RHEL7 kernel);
- kernel is unable to reclaim the kernel memory so once the limit is
hit a cgroup is toasted;
- some kernel memory allocations don't allow failing.
In addition to that,
- users don't have a clue about how to set kernel memory limits
(as the concept is much more complicated than e.g. [user] memory);
- different kernels might have different kernel memory usage,
which is sort of unexpected;
- cgroup v2 do not have a [dedicated] kmem limit knob, and thus
runc silently ignores kernel memory limits for v2;
- kernel v5.4 made cgroup v1 kmem.limit obsoleted (see
https://github.com/torvalds/linux/commit/0158115f702b).
In view of all this, and as the runtime-spec lists memory.kernel
and memory.kernelTCP as OPTIONAL, let's ignore kernel memory
limits (for cgroup v1, same as we're already doing for v2).
This should result in less bugs and better user experience.
The only bad side effect from it might be that stat can show kernel
memory usage as 0 (since the accounting is not enabled).
[v2: add a warning in specconv that limits are ignored]
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
The man-pages are using pre-formatted section to display the options for
all commands. The result on my system never looked correct:
OPTIONS
--bundle value, -b value path to the root [...]
--console-socket value path to an AF_UNIX [...]
The first line was always indented less than the other lines.
This commit makes the option block a pre-formatted block (as intended???) by
using 4 spaces instead of 3 spaces.
In addition the man-pages did not specify their name and section
correctly. This adds something like '% runc-run "8"' to all man-pages to
have correct title 'runc-run(8)' instead of 'NAME()' and it also adds
the section to the title: 'System Manager's Manual'.
This also fixes the use of '>' and '<' at multiple places. The markdown
source files were using "<container-id>" and similar which was (most of
the time) rendered as '""'. On some systems it was rendered correctly.
Signed-off-by: Adrian Reber <areber@redhat.com>
If 'go-md2man' is not installed,
an error can occur when running md2man-all.sh like below:
$ ./man/md2man-all.sh -q
./man/md2man-all.sh: line 21: go-md2man: command not found
So fix it.
Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
The commit 244c9fc ("*: console rewrite")
removed the --console option and the commit 7df64f8
("runc: implement --console-socket") create new option
--console-socket. However, the old --console option
still exists so fix it.
In addtion, add missing --preserve-fds option to
create and run manpages.
Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
Signed-off-by: charsyam <charsyam@naver.com>
This flag allows specifying additional gids for the process.
Without this flag, the user will have to provide process.json which allows additional gids.
Closes#1306
Signed-off-by: Sumit Sanghrajka <sumit.sanghrajka@gmail.com>
As per the discussions in #1156 , we think it's a bad
idea to allow multi container operations in runc. So
revert it.
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
CRIU gets pre-dump to complete iterative migration.
pre-dump saves process memory info only. And it need parent-path
to specify the former memory files.
This patch add pre-dump and parent-path arguments to runc checkpoint
Signed-off-by: Deng Guangxing <dengguangxing@huawei.com>
Signed-off-by: Adrian Reber <areber@redhat.com>
This allows a user to send a signal to all the processes in the
container within a single atomic action to avoid new processes being
forked off before the signal can be sent.
This is basically taking functionality that we already use being
`delete` and exposing it ok the `kill` command by adding a flag.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Currently runc already supports setting realtime runtime and period
before container processes start, this commit will add update support
for realtime scheduler resources.
Signed-off-by: Zhang Wei <zhangwei555@huawei.com>
With this patch, `runc start` command can start mulit-containers
at one command this patch also checks the argument of the `start`
command.
root@ubuntu:# runc list
ID PID STATUS BUNDLE CREATED
a 0 stopped /mycontainer 2016-09-23T08:56:42.754026567Z
b 62979 created /mycontainer 2016-09-23T09:01:36.421976458Z
c 62993 running /mycontainer 2016-09-23T09:01:38.105940389Z
d 63006 created /mycontainer 2016-09-23T09:01:39.65441942Z
e 63020 created /mycontainer 2016-09-23T09:01:40.989995515Z
root@ubuntu:# runc start
runc: "start" requires a minimum of 1 argument
root@ubuntu:# runc start a b c d e f
cannot start a container that has run and stopped
cannot start an already running container
container f is not exist
all or part of the containers start failed
root@ubuntu:# runc list
ID PID STATUS BUNDLE CREATED
a 0 stopped /mycontainer 2016-09-23T08:56:42.754026567Z
b 62979 running /mycontainer 2016-09-23T09:01:36.421976458Z
c 62993 running /mycontainer 2016-09-23T09:01:38.105940389Z
d 63006 running /mycontainer 2016-09-23T09:01:39.65441942Z
e 63020 running /mycontainer 2016-09-23T09:01:40.989995515Z
Signed-off-by: Wang Long <long.wanglong@huawei.com>
lifubang