The default values of masked and readonly paths are defined
in populateDefaultUnixSpec, and are used when a sandbox is
created. It is not, however, used for new containers. If
a container definition does not contain a security context
specifying masked/readonly paths, a container created from
it does not have masked and readonly paths.
This patch applies the default values to masked and
readonly paths of a new container, when any specific values
are not specified.
Fixes#1569
Signed-off-by: Yohei Ueda <yohei@jp.ibm.com>
Fix restoring from a checkpoint image always getting skipped when no checkpoint image path is set. As one restores either from an image OR a path, this makes no sense.
Signed-off-by: Jakob Schrettenbrunner <dev@schrej.net>
Starting with go1.14, the go runtime hijacks SIGURG but with no way to
not send to other signal handlers.
In practice, we get this signal frequently.
I found this while testing out go1.15 with ctr and multiple execs with
only `echo hello`. When the process exits quickly, if the previous
commit is not applied, you end up with an error message that it couldn't
forward SIGURG to the container (due to the process being gone).
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Previously the signal loop can end up racing with the process exiting.
Intead of logging and continuing the loop, exit early.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
On the very popular Raspberry Pi 1 and Zero devices, the CPU is actually ARMv6, but the chip happens to support the feature bit the kernel uses to differentiate v6/v7, so it gets reported as "CPU architecture: 7" and thus fails to run many of the images that get pulled.
To account for this very popular edge case, this also checks "model name" which on these chips will begin with "ARMv6-compatible" -- we could also check uname, but getCPUInfo is already handy, low overhead, and mirrors the code before this.
Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
This accomplishes a few long-standing TODO items, but also helps users
in showing exact registry error messages
Signed-off-by: Ilya Dmitrichenko <errordeveloper@gmail.com>
This `Info` log shows up for all exec processes that use the v1 shim
with Docker because Docker deletes the process once it receives the exit
event from containerd.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Put the overlay plugin in a separate package to allow the overlay package to be
used without needing to import and initialize the plugin.
Signed-off-by: Derek McGowan <derek@mcg.dev>
This allows configuring the location of the overlayfs snapshotter by
adding the following in config.toml
```
[plugins]
[plugins.overlayfs]
root_path = "/custom_location"
```
This is useful to isolate disk i/o for overlayfs from the rest of
containerd and prevent containers saturating disk i/o from negatively
affecting containerd operations and cause timeouts.
Signed-off-by: Ashray Jain <ashrayj@palantir.com>
Currently the shims only support starting the logging binary process if the
io.Creator Config does not specify Terminal: true. This means that the program
using containerd will only be able to specify FIFO io when Terminal: true,
rather than allowing the shim to fork the logging binary process. Hence,
containerd consumers face an inconsistent behavior regarding logging binary
management depending on the Terminal option.
Allowing the shim to fork the logging binary process will introduce consistency
between the running container and the logging process. Otherwise, the logging
process may die if its parent process dies whereas the container will keep
running, resulting in the loss of container logs.
Signed-off-by: Akshat Kumar <kshtku@amazon.com>
