You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 12, 2021. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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 ?
Description of problem
If an executeable is shared with
runc
andkata-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#135Steps to reproduce:
Open two terminals and run both commands:
If I execute the kata container first, than the runc container fails with:
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
andkata
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
withkata
containers (and don't use--init
) to avoid this issue.Possible solution for
--init
: kata could ship with its owntini
binary.Side note:
/usr/bin/docker-init
is missing on rpm based systems like fedora and--init
fails there anyway.Actual result
Using
--init
withrunc
andkata-runtime
at the same time causes the second runtime container to fail.The text was updated successfully, but these errors were encountered: