We may consider setting it to true all the time but this
should match our previous behavior before we started
using process json for exec.
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
The old "won't never" was a potentially-confusing double negative.
This commit rewords the comment to avoid that issue and also lands
some other minor cleanups.
Signed-off-by: W. Trevor King <wking@tremily.us>
We leave the stdin open on first client disconnect if stdin once
is not set in the container configuration.
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
Some oci runtimes may used stderr for logging. Cri-o should not try to
parse this output as json when calling the "state" command.
Signed-off-by: Nicolas Lacasse <nlacasse@google.com>
This patch fixes exec to use the original (start-time) process exec
configuration. Otherwise, we were creating a brand new spec process w/o
additional groups for instance.
Spotted while integrating CRI-O with cri-test...The test was failing
with:
```
• Failure [10.640 seconds]
[k8s.io] Security Context
/home/amurdaca/go/src/github.com/kubernetes-incubator/cri-tools/pkg/framework/framework.go:72
bucket
/home/amurdaca/go/src/github.com/kubernetes-incubator/cri-tools/pkg/validate/security_context.go:407
runtime should support SupplementalGroups [It]
/home/amurdaca/go/src/github.com/kubernetes-incubator/cri-tools/pkg/validate/security_context.go:272
Expected
<[]string | len:1, cap:1>: ["0"]
to contain element matching
<string>: 1234
```
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
It always fails because conmon is still there.
But more importantly it adds a 2 seconds delay to the container
creation as we're trying to delete a cgroup but we can't.
With this patch a container creation is down to typically less than
150ms instead of 2+ seconds.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Under very heavy loads (e.g. 100 pods created at the same time), VM
based runtimes can take more than 10 seconds to create a pod.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When cri-o assumes the container creation failed, we need to let the
runtime know that we're bailing out so that it cancels all ongoing
operation.
In container creation timeout situations for example, failing to
explictly request the runtime for container deletion can lead to large
resource leaks as kubelet re-creates a failing container, while the
runtime finishes creating the previous one(s).
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Set the exitsdir for kpod back to /var/run/crio... so kpod can benefit
from the container exit file.
Because 0 is the int32 blank value, kpod needs its own container state
struct with the omitempty removed so it can actually display 0 in
its default json output.
Signed-off-by: baude <bbaude@redhat.com>
runc has a `--no-pivot` flag, that uses MS_MOVE instead.
This patch set bubbles up a runtime config to enable using no-pivot
globally.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Implement the ability to pause and unpause running containers.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Signed-off-by: TomSweeneyRedHat <tsweeney@redhat.com>
This allows the container list API to return updated status
for exited container without having to call container status first.
Signed-off-by: Mrunal Patel <mpatel@redhat.com>
Need to mv to latest released and supported version of logrus
switch github.com/Sirupsen/logrus github.com/sirupsen/logrus
Also vendor in latest containers/storage and containers/image
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
The syscall package is locked down and the comment in [1] advises to
switch code to use the corresponding package from golang.org/x/sys. Do
so and replace usage of package syscall where possible (leave
syscall.SysProcAttr and syscall.Stat_t).
[1] https://github.com/golang/go/blob/master/src/syscall/syscall.go#L21-L24
This will also allow to get updates and fixes just by re-vendoring
golang.org/x/sys/unix instead of having to update to a new go version.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
This moves the timeout handling from the go code to conmon, whic
removes some of the complexity from criod, and additionally it will
makes it possible to do the double-fork in the exec case too.
Signed-off-by: Alexander Larsson <alexl@redhat.com>
Currently, when creating containers we never call Wait on the
conmon exec.Command, which means that the child hangs around
forever as a zombie after it dies.
However, instead of doing this waitpid() in the parent we instead
do a double-fork in conmon, to daemonize it. That makes a lot of
sense, as conmon really is not tied to the launcher, but needs
to outlive it if e.g. the cri-o daemon restarts.
However, this makes even more obvious a race condition which we
already have. When crio-d puts the conmon pid in a cgroup there
is a race where conmon could already have spawned a child, and
it would then not be part of the cgroup. In order to fix this
we add another synchronization pipe to conmon, which we block
on before we create any children. The parent then makes sure the
pid is in the cgroup before letting it continue.
Signed-off-by: Alexander Larsson <alexl@redhat.com>
Container runtimes provide different levels of isolation, from kernel
namespaces to hardware virtualization. When starting a specific
container, one may want to decide which level of isolation to use
depending on how much we trust the container workload. Fully verified
and signed containers may not need the hardware isolation layer but e.g.
CI jobs pulling packages from many untrusted sources should probably not
run only on a kernel namespace isolation layer.
Here we allow CRI-O users to define a container runtime for trusted
containers and another one for untrusted containers, and also to define
a general, default trust level. This anticipates future kubelet
implementations that would be able to tag containers as trusted or
untrusted. When missing a kubelet hint, containers are trusted by
default.
A container becomes untrusted if we get a hint in that direction from
kubelet or if the default trust level is set to "untrusted" and the
container is not privileged. In both cases CRI-O will try to use the
untrusted container runtime. For any other cases, it will switch to the
trusted one.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
We use a SOCK_SEQPACKET socket for the attach unix domain socket, which
means the kernel will ensure that the reading side only ever get the
data from one write operation. We use this for frameing, where the
first byte is the pipe that the next bytes are for. We have to make sure
that all reads from the socket are using at least the same size of buffer
as the write side, because otherwise the extra data in the message
will be dropped.
This also adds a stdin pipe for the container, similar to the ones we
use for stdout/err, because we need a way for an attached client
to write to stdin, even if not using a tty.
This fixes https://github.com/kubernetes-incubator/cri-o/issues/569
Signed-off-by: Alexander Larsson <alexl@redhat.com>
