Help debugging with cri-o #35
Comments
|
thanks for the report! I am currently working on support for CRI-O. My WIP is here: cri-o/cri-o#2239. I am still seeing some issues in crun that prevents the integration and e2e tests to pass but I am working on it. Is there a way to store the config.json file for the container that is failing? That would make much easier to debug the issue, if not, I'll try to reproduce locally. /cc @mrunalp |
|
|
hopefully that's useful... |
|
thanks, that is helpful. I've added a patch that catches earlier the error in opening the cgroup directory, but that is not enough yet to address the issue. What distro and kernel are you using? |
|
Gentoo, kernel 5.0.7, openrc |
|
this probably isn't helpful, but when I set the runtime to runc the .linux.cgroupsPath is created |
|
I've just merged some patches that let the CRI-O integration tests pass successfully (except for three tests that are dependent on a runc behaviour). There were no changes needed in the cgroup part though, I'll need to look at this separately |
|
any hint on what is the quickest way to get access to your same environment? I've tried a vagrant machine for Gentoo but it seems to get stuck. If there is nothing easier, I'll try to go through the full installation |
|
MacOS as the base machine? Another option is a VPS, I use Gentoo on https://linode.com |
|
I would say Alpine, but I don't think they have a cri-o package yet. |
giuseppe
referenced
this issue
Apr 18, 2019
the issue didn't occur on Fedora as both cpu and cpu,cpuacct are linked to the same directory, while it happens if the two subsystems are mounted separately, such as on Gentoo+openrc. Closes: https://github.com/giuseppe/crun/issues/35 Signed-off-by: Giuseppe Scrivano <giuseppe@scrivano.org>
|
I compiled patch #41 , and I'm getting this in the cri-o logs: |
|
do you have anything under I've seen that issue in the past, it depends on XDG_RUNTIME_DIR that is not always set. I'll need to find a better way to address that. I don't like much the way runc does it as it detect whether runc is running in a user namespace, but probably there are no better alternatives to it |
|
if you have anything under |
|
Okay I'll double check |
|
might be caused by 4966bb6 that was recently merged |
|
so on this machine I don't have a /run/user dir |
|
is |
|
doesn't look like it |
|
thanks to check this out, what about the CRI-O process? |
|
on my Linode Gentoo VM I don't see Could you revert 4966bb6 and see if that is the issue? |
|
okay the crio process has no XDG_RUNTIME_DIR var, and reverting 4966bb6 didn't seem to help |
|
just pulled down master still unable to find /run/crun//status |
|
I'll give it another attempt in the next days (I am quite sure it is some weird interaction of XDG_RUNTIME_DIR). (just Fedora for now, as the RHEL failures are expected for a missing package) |
|
it seems it gets confused on Gentoo as there is no pids cgroup controller? |
|
|
test suite passes now |
|
crio conmon does have the XDG_RUNTIME variable but it's not set |
|
I finally managed to pass the Kubernetes e2e tests with CRI-O and crun |
|
Coolio! But, getting back to business. I compiled master this morning (eastern US) and I was still having the same status file not found error. So I searched for status in the Repo, and took a closer look at this function; so on a whimsy I did a ls on / and there is was, the /crun folder. |
|
good hint! So I guess the issue is in the XDG_RUNTIME_DIR to be defined but empty. Is this patch making any difference? |
|
I need a couple of minutes to finish up another task, I'll check as soon as I can |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I keep getting this when I try and create a container:
level=error msg="Container creation error: writing file 'cpu.shares': Bad file descriptorNotice crio-UUID is missing
The text was updated successfully, but these errors were encountered: