Most of whatever is happening in the test cases is already available in
setup_hello and teardown_hello. Use these.
Rewrite the validation test to be more compact and not dependent
on `pwd` value. Also, pinning xeipuuv/gojsonschema to a particular
version is no longer required.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
The purpose of the spec validation test is to make sure
that config.json generated by runc spec is valid. Therefore,
it does not depend on ROOTLESS_FEATURES.
Taking that into account, and given the fact that this test
involves cloning repos and building some code, it makes sense
to not run it 4 times for various rootless features.
Time it takes to execute spec.bats in rootless mode has improved.
Before:
real 0m21.286s
user 0m37.837s
sys 0m5.745s
After:
real 0m13.162s
user 0m30.814s
sys 0m4.050s
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Commit d78ae51a2 adds this line, but the file is never created.
This is probably a leftover from copy-pasting update.bats code.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
With some grep|awk help, found a few places where the containers
supposed to be removed in teardown() weren't.
To find container names:
grep -E '^[[:space:]]*\<_*_*runc\>.*\<(create|run|restore)\>'
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This was a workaround for RHEL6 (2.6.xx) kernels, which have not
been supported by container runtimes for a long time, so should
be safe to remove this workaround.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit a08ab87fe added these targets. Alas, the `go mod tidy` never
worked, as it was written as part of `export` statement:
export GO111MODULE=on \
$(GO) mod tidy && \
...
which is the same as
export GO111MODULE=on $(GO) mod tidy && ...
which exports a bunch of variables, such as `go`, `mod`, and `tidy`,
but does not run it.
The fix would be to add a semicolon after the `export` statement,
but since GO111MODULE is not really needed here (maybe some older
golang versions needed it?), let's just drop it.
With this dropped, && does not make any sense, so drop it, too.
NOTE that if someone tries
GO111MODULE=off make vendor
it will fail, but I guess it is expected.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
full diff: https://github.com/moby/sys/compare/mountinfo/v0.1.3...mountinfo/v0.2.0
Bug fixes:
- Fix path unescaping for paths with double quotes
Improvements:
- Mounted: speed up by adding fast paths using openat2 (Linux-only) and stat
- Mounted: relax path requirements (allow relative, non-cleaned paths, symlinks)
- Unescape fstype and source fields
- Documentation improvements
Testing/CI:
- Unit tests: exclude darwin
- CI: run tests under Fedora 32 to test openat2
- TestGetMounts: fix for Ubuntu build system
- Makefile: fix ignoring test failures
- CI: add cross build
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
As the underlying error message from iotuils.WriteFile already contains
file name, there's no need to put it, otherwise we end up with something
like:
failed to write "val" to "/sys/fs/cgroup/.../file": open /sys/fs/cgroup/.../file: permission denied
With this patch, the error will be
failed to write "val": open /sys/fs/cgroup/.../file: permission denied
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
For test cases where we used pipes for container's stdin/stdout/stderr,
stderr was redirected to the same pipe as stdout, which practically
means it is lost.
These redirects to fd is needed not because we check that container is
working by writing to its stdin and reading from stdout (see
check_pipes), but also because bats redirects test stdout/stderr to a
file, which makes c/r impossible (as the file is outside of container).
This is why we can't just do something like `2>stderr.log`, and have
to do what is done in this commit.
Introduce and use another pipe for stdout, to be used for both runc run
and runc restore, so it will be shown in case of errors.
Since its handling is somewhat complicated and is used from 4 places
(2 for run, 2 for restore), separate it into a helper functions.
NOTE the code assumes that runc exits with non-zero exit code in case
there is anything that needs to be shown to a user from runc's stderr.
While at it, add error checking to runc run calls.
Hopefully, this will help debug those rare checkpoint failures in CI.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Commit 417f5ff40 added a code to close fds and kill processes, which
should have helped in an event of test case failure.
In fact, each test case is executed in a subshell, so
- any variables set there can't reach teardown();
- all the fds are closed (as the process is gone).
Now, I am not sure about the processes, but the code being removed
has never worked anyway, so it does not make sense to keep it.
Normally, those are waited for. In case of a test case failure,
well, the subsequent cases might fail, too.
Fixes: 417f5ff40d
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This fixes the following issue with the test:
not ok 12 checkpoint --lazy-pages and restore
# (in test file tests/integration/checkpoint.bats, line 202)
# `[ $ret -eq 0 ]' failed
...
# grep: ./work-dir/restore.log: No such file or directory
One might think that `--work-path ./image-dir` is a mistake, but it's
not, since `criu lazy-pages -D ./image-dir` creates a socket in
./image-dir, and then `criu restore --lazy-pages` expects a socket in
the workdir.
Fixes: e232a71a3d
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
These tests expect group name to be "nogroup", while recent busybox
changed that to "nobody".
Use numeric uids/gids to fix.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This test started to fail, as it expected the output from
`id` to be
uid=1000 gid=1000 groups=100(users),65534(nogroup)
while the actual output is now
uid=1000 gid=1000 groups=100(users),65534(nobody)
Apparently, busybox image changed group name.
As we're only interested in ids, not names, and to fix the test,
let's use `id -G`.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
If the procRun state has been synced and the runc-create process has
been killed for some reason, the runc-init[2:stage] process will be
leaky. And the runc command also fails to parse root directory because
the container doesn't have state.json.
In order to make it possible to clean the leaky runc-init[2:stage]
process , we should store the status before sync procRun.
```before
current workflow:
[ child ] <-> [ parent ]
procHooks --> [run hooks]
<-- procResume
procReady --> [final setup]
<-- procRun
( killed for some reason)
( store state.json )
```
```expected
expected workflow:
[ child ] <-> [ parent ]
procHooks --> [run hooks]
<-- procResume
procReady --> [final setup]
store state.json
<-- procRun
```
Signed-off-by: Wei Fu <fuweid89@gmail.com>
It's expect that signalAllProcesses is invoked when container shares
pid namespace. share pid ns contains the following conditions:
{
// no specify pid ns
}
{
"type": "pid",
"path": "/proc/${num}/ns/pid"
}
Signed-off-by: Shukui Yang <jryangshukui@jd.com>
Signed-off-by: Shukui Yang <keloyangsk@gmail.com>
In all these cases, getSubsystemPath() was already called, and its
result stored in m.paths map. It makes no sense to not reuse it.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
We call joinCgroups() from Apply, and in there we iterate through the
list of subsystems, calling getSubsystemPath() for each. This is
expensive, since every getSubsystemPath() involves parsing mountinfo.
At the end of Apply(), we iterate through the list of subsystems to fill
the m.paths, again calling getSubsystemPath() for every subsystem.
As a result, we parse mountinfo about 20 times here.
Let's find the paths first and reuse m.paths in joinCgroups().
While at it, since join() is just two calls now, inline it.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
When paths are set, we only need to place the PID into proper
cgroups, and we do know all the paths already.
Both fs/d.path() and systemd/v1/getSubsystemPath() parse
/proc/self/mountinfo, and the only reason they are used
here is to check whether the subsystem is available.
Use a much simpler/faster check instead.
Frankly, I am not sure why the check is needed at all. Maybe it should
be dropped.
Also, for fs driver, since d is no longer used in this code path,
move its initialization to after it.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This looks like this is just filling logs for years, since the kernel never
added the support for automatically labeling /dev/mqueue.
Removes these dmesg lines
[ 1731.969847] SELinux: mount invalid. Same superblock, different security settings for (dev mqueue, type mqueue)
[ 1736.985146] SELinux: mount invalid. Same superblock, different security settings for (dev mqueue, type mqueue)
[ 1738.356796] SELinux: mount invalid. Same superblock, different security settings for (dev mqueue, type mqueue)
[ 1738.479952] SELinux: mount invalid. Same superblock, different security settings for (dev mqueue, type mqueue)
[ 1738.628935] SELinux: mount invalid. Same superblock, different security settings for (dev mqueue, type mqueue)
[ 1763.433276] SELinux: mount invalid. Same superblock, different security settings for (dev mqueue, type mqueue)
[ 1806.802133] SELinux: mount invalid. Same superblock, different security settings for (dev mqueue, type mqueue)
[ 1806.982003] SELinux: mount invalid. Same superblock, different security settings for (dev mqueue, type mqueue)
[ 1808.955390] SELinux: mount invalid. Same superblock, different security settings for (dev mqueue, type mqueue)
[ 1815.951076] SELinux: mount invalid. Same superblock, different security settings for (dev mqueue, type mqueue)
[ 1827.257757] SELinux: mount invalid. Same superblock, different security settings for (dev mqueue, type mqueue)
[ 1828.947888] SELinux: mount invalid. Same superblock, different security settings for (dev mqueue, type mqueue)
[ 1834.964451] SELinux: mount invalid. Same superblock, different security settings for (dev mqueue, type mqueue)
[ 1835.941465] SELinux: mount invalid. Same superblock, different security settings for (dev mqueue, type mqueue)
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
The `apparmor_parser` binary is not really required for a system to run
AppArmor from a runc perspective. How to apply the profile is more in
the responsibility of higher level runtimes like Podman and Docker,
which may do the binary check on their own.
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
Sebastiaan van Stijn