This repository has been archived by the owner on Jan 4, 2022. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With runc 1.0.0-rc2 on Container Linux 1465, kube-spawn init hangs forever with message like:
"Created API client, waiting for the control plane to become ready"
. That's because docker daemon cannot execute runc, which returns error like"no subsystem for mount"
.See also: opencontainers/runc#1175 (comment)
This issue was apparently resolved in runc 1.0.0-rc3, so in theory runc 1.0.0-rc3 should work fine with Docker 17.05. Unfortunately on Container Linux, it's not trivial to replace only the runc binary with a custom one, because Container Linux makes use of torcx to provide
docker as well as runc:
/run/torcx/unpack
is sealed, read-only mounted.As workaround, we should change cgroupdriver for docker and kubelet from systemd to cgroupfs. Then init process will succeed without hanging forever.
See also #45