Skip to content
This repository has been archived by the owner on May 12, 2021. It is now read-only.

Sharing executeables with runc and kata fails / --init #1901

Closed
mviereck opened this issue Jul 21, 2019 · 1 comment
Closed

Sharing executeables with runc and kata fails / --init #1901

mviereck opened this issue Jul 21, 2019 · 1 comment
Labels
bug Incorrect behaviour needs-review Needs to be assessed by the team.

Comments

@mviereck
Copy link

mviereck commented Jul 21, 2019

Description of problem

If an executeable is shared with runc and kata-runtime containers at the same time, it can be run in only one of them. It will fail in the other one.

I use /usr/bin/docker-init (tini of option --init) as an example, but it applies to other executeables, too.

I have encountered segmentation faults with kata 1.5.3.
Now I have kata 1.8.0-rc0. It still fails, but now with no message at all.

Compare this ticket with some strace analysis: krallin/tini#135

# strace -- /docker-init -- true
execve("/docker-init", ["/docker-init", "--", "true"], 0x7fff0a3edc18 /* 8 vars */) = -1 ETXTBSY (Text file busy)
+++ killed by SIGSEGV +++
Segmentation fault

Steps to reproduce:

Open two terminals and run both commands:

docker run --rm -v /usr/bin/docker-init:/tini --runtime=runc -- alpine /tini sleep 10
docker run --rm -v /usr/bin/docker-init:/tini --runtime=kata-runtime -- alpine /tini sleep 10

If I execute the kata container first, than the runc container fails with:

standard_init_linux.go:211: exec user process caused "text file busy"

Same occurs if using option --init directly, but this way it is easier to look at.

Expected result

A failure for arbitrary executeables shared with runc and kata at the same time might be reasonable. Probably it will be a rare case, after all.
Maybe kata could check if other processes access shared files at the same time and somehow catch this case.

A solution should be found for option --init. For my own use cases I share a copy of /usr/bin/docker-init with kata containers (and don't use --init) to avoid this issue.

Possible solution for --init: kata could ship with its own tini binary.

Side note: /usr/bin/docker-init is missing on rpm based systems like fedora and --init fails there anyway.

Actual result

Using --init with runc and kata-runtime at the same time causes the second runtime container to fail.

@mviereck mviereck added bug Incorrect behaviour needs-review Needs to be assessed by the team. labels Jul 21, 2019
@grahamwhaley
Copy link
Contributor

Ouch. I'm not sure I've seen anybody try this before. thanks for reporting @mviereck , and with nice details.
@gnawux @bergwolf - have you run across this in any of your previous setups and work ?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Incorrect behaviour needs-review Needs to be assessed by the team.
Projects
None yet
Development

No branches or pull requests

3 participants