-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replacing oci-runc with sysbox-runc results in EOF errors #765
Comments
Thanks for giving Sysbox a shot for this use-case. Sysbox is made up of 3 components: sysbox-runc, sysbox-fs, and sysbox-mgr. The latter two must be running before launching a container. Once containerd starts the container, it will talk to sysbox-runc, which will then communicate with the sysbox-mgr and sysbox-fs to setup the container. Question: did you start sysbox-mgr and sysbox-fs? There's a script here that can start the sysbox components on a host with or without systemd. I encourage you to leverage that if possible, or at least take a look at how it starts Sysbox. Let me know if this helps. Thanks again! |
BTW, this error:
means that as soon as the sysbox-runc started the container process in it's namespaces, the process died (so it never communicated back with sysbox-runc to say "I am ready to go"). That could happen for many reasons, but if sysbox-fs and sysbox-mgr are not running, there's no point in debugging it. |
No I did not. I assumed (incorrectly) that sysbox-runc was all that was needed. I will attempt to run these and get back. |
I can confirm that sysbox-fs and sysbox-mgr are running (both in /usr/bin). I now get different errors than before:
It looks to me that the hostID for containerID 0 is maxint or -1 (unsigned). This is the error I get if I symlink my oci-runc for |
@ctalledo Thank you for the help so far. I have more information. Rather than get this to work with concourse, I figure I would check to make sure everything is working with docker and containerd. It is not. /etc/docker/daemon.json
All services have been restarted, etc. docker info | grep runtime
This looks like it may work. Indeed I can start various containers such as "alpine" and "busybox". However I then try to run a container that accesses /var/fs/cgroup.
I think it clearly makes sense to get this working before attempting to get it working in concourse. |
Update here that I am able to get sysbox-runc working with docker. Using docker:dind image confirms that docker-in-docker can run without "--privileged". However when I start concourse it directly talks to containerd, and I am presuming it is using a regular runc at this point. |
That error sounds like the
Ok cool!
I am not familiar with concourse, but is there a flag similar to Docker's
That error makes sense to me: the mount is blocked because the container is unprivileged; if we were to allow it, the container would gain access of the cgroups for the entire system (including other containers, etc.) I wonder though, why is the
|
The contents of
I generally don't know anything about these files. |
OK that looks good: it's saying that user That means that the But sounds like we don't want to focus on this error yet correct? |
Not that I'm aware of. There is a way to pass a |
What I know right now is:
|
'm symlinking my otherwise oci spec compatible runc binary to point over to sysbox-runc, and that's when I'm getting the error. My understanding is that the host ID issue is unexpected. Can you confirm that? I think if that is unexpected from the project, that's something I could use help debugging. |
Oh I see; that should work though. On my host, I symlinked
Correct, it's unexpected. As you mentioned, it seems like a -1 (unsigned) bug somewhere, but I've never seen it.
If concourse does not have a flag to select the runtime, then there's a way to configure the "default runtime" in containerd via the /etc/containerd/config.toml file. Alternatively the symlinking should have worked. There's also a tool called crictl that allows you to talk to containerd directly (i.e., you can use it to pull images, start containers, etc.). You could try it as a way of testing just containerd + sysbox works, and then bring concourse into the picture. If containerd + sysbox fails with the HostID error above, then it's definitely a Sysbox bug or a misconfig somewhere, and happy to help you debug it. |
I am attempting to add sysbox-runc to a concourse ci worker. The concourse deployment is a tarball of binaries including but not limited to containerd, containerd-shim's, init, ctr, runc, and concourse binaries. The binaries refer to another in relative paths, meaning they do not rely on a package manager or systemd. I am mentioning this because there is no docker, and containerd is not installed on the system as a service.
Ultimately I am attempting to enable concourse to run docker-in-container workflows without passing in a privileged flag (on of sysbox's use cases).
Concourse allows using one of three container managers (guardian, containerd, and houdini). For the purposes of this bug, concourse is configured to use containerd.
I attempted to symlink the runc binary to /bin/sysbox-runc, and I also attempted to set a configuration file on containerd so that it would recognize sysbox-runc as its default runtime. In both cases sysbox failed to launch containers.
Error:
Expected output:
The container should be created and the job run in the container
System information:
Linux 5.19.0-45-generic #46~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Jun 7 15:06:04 UTC 20 x86_64 x86_64 x86_64 GNU/Linux
Concourse packaged runc information:
Because the spec is 1.0.2-dev I used sysbox-ce_0.6.2:
I was able to directly call sysbox-runc by creating a rootfs and calling
sudo sysbox-runc run foobar
. Hypothetically, I think the error may have to do with either how pipes or user mappings, or something else is managed between containerd, containerd-shim-runc-v2, and sysbox-runc?The text was updated successfully, but these errors were encountered: