Files
runc/tests/integration
Kir Kolyshkin 5d0ffbf9c8 runc start/run: report OOM
In some cases, container init fails to start because it is killed by
the kernel OOM killer. The errors returned by runc in such cases are
semi-random and rather cryptic. Below are a few examples.

On cgroup v1 + systemd cgroup driver:

> process_linux.go:348: copying bootstrap data to pipe caused: write init-p: broken pipe

> process_linux.go:352: getting the final child's pid from pipe caused: EOF

On cgroup v2:

> process_linux.go:495: container init caused: read init-p: connection reset by peer

> process_linux.go:484: writing syncT 'resume' caused: write init-p: broken pipe

This commits adds the OOM method to cgroup managers, which tells whether
the container was OOM-killed. In case that has happened, the original error
is discarded (unless --debug is set), and the new OOM error is reported
instead:

> ERRO[0000] container_linux.go:367: starting container process caused: container init was OOM-killed (memory limit too low?)

Also, fix the rootless test cases that are failing because they expect
an error in the first line, and we have an additional warning now:

> unable to get oom kill count" error="no directory specified for memory.oom_control

Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
2021-02-23 16:15:33 -08:00
..
2021-02-23 16:15:33 -08:00
2021-02-08 14:14:14 +01:00
2021-02-02 16:03:29 -08:00
2021-02-02 16:03:29 -08:00
2021-02-02 16:03:29 -08:00
2021-01-28 13:13:56 -08:00
2020-11-27 14:15:32 -08:00
2020-09-21 02:47:23 -07:00

runc Integration Tests

Integration tests provide end-to-end testing of runc.

Note that integration tests do not replace unit tests.

As a rule of thumb, code should be tested thoroughly with unit tests. Integration tests on the other hand are meant to test a specific feature end to end.

Integration tests are written in bash using the bats (Bash Automated Testing System) framework.

Running integration tests

The easiest way to run integration tests is with Docker:

$ make integration

Alternatively, you can run integration tests directly on your host through make:

$ sudo make localintegration

Or you can just run them directly using bats

$ sudo bats tests/integration

To run a single test bucket:

$ make integration TESTPATH="/checkpoint.bats"

To run them on your host, you need to set up a development environment plus bats (Bash Automated Testing System).

For example:

$ cd ~/go/src/github.com
$ git clone https://github.com/bats-core/bats-core.git
$ cd bats-core
$ ./install.sh /usr/local

Note

: There are known issues running the integration tests using devicemapper as a storage driver, make sure that your docker daemon is using aufs if you want to successfully run the integration tests.

Writing integration tests

[helper functions] (https://github.com/opencontainers/runc/blob/master/tests/integration/helpers.bash) are provided in order to facilitate writing tests.

#!/usr/bin/env bats

# This will load the helpers.
load helpers

# setup is called at the beginning of every test.
function setup() {
  # see functions teardown_hello and setup_hello in helpers.bash, used to
  # create a pristine environment for running your tests
  teardown_hello
  setup_hello
}

# teardown is called at the end of every test.
function teardown() {
  teardown_hello
}

@test "this is a simple test" {
  runc run containerid
  # "The runc macro" automatically populates $status, $output and $lines.
  # Please refer to bats documentation to find out more.
  [ "$status" -eq 0 ]

  # check expected output
  [[ "${output}" == *"Hello"* ]]
}