-
Notifications
You must be signed in to change notification settings - Fork 33
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
Docker run lines don't report completion #21
Comments
Yes it worked in the past (back in July) I’m also getting this issue now. One thing that’s to be noted as well is that if you ^C docker build, then restart the job it will finish normally, even with --no-cache. |
I haven't had the time to take a look at @gizahNL's moby port at all yet, so I'm not going to be a ton of help in debugging whether there's an issue at that layer or not. I do see the following log line which makes me think that moby might be receiving an exit but not processing it, though this is definitely not conclusive:
These lines from the containerd log (really from the shim) seem to indicate that the container exited:
In these logs you can see pid 88058 was the main process for the container. This is initially the I did just make changes to how
The shim sets itself up as a subreaper with Anyway, I think it'd help to try the following things:
|
Yup, that fixes it! I rolled back to a37cfff and
It looks as if the stopped ones can't be cleaned up by
This hangs, as previously. From another terminal:
It looks as if the moby build is still assuming linux things and needs to generate a FreeBSD container config on FreeBSD.
This is suspicious - not sure why it thinks the pid is 0, pid 0 is the kernel. I presume 0 is a placeholder here for pid-not-known?
The
So it looks as if the runj shim is still running but it has cleaned up all of the associated state? |
I'm not 100% sure that the cause is the new code or if it's a race condition that is triggered more of the time in the new code. I had a container hang after trying to run Restarting
|
Yeah moby writes out a default config containing many linuxisms, they're all ignored by runj and containerd though. |
This isn't a problem with runj itself. In my work-in-progress port of buildah, I tried this example build:
and got the expected results:
|
I'm not sure if this is a problem with runj, the containerd shim, or with the moby port (from https://github.com/gizahNL/moby), but If I write this minimal Dockerfile:
Running docker build prints hello but doesn't detect that the command has completed:
It hangs at this point and does not advance.
docker --debug
produces this output:At the same time,
containerd -l debug
produces this:It looks as if it's tracking two processes in the jail. I'm not sure why the second exits first (maybe they exit at about the same time and are reported in different orders?). At the end of this, I would expect
runj
to report that the command finished.If I restart
dockerd
, it notices that it has a container that appears to be running that it doesn't know about and tries to kill it:This triggers the following output from
containerd
:Again, it looks as if
runj
is generating a log message indicating that the process has exited, but isn't reporting the exit tocontainerd
?I can kill the jails with
jail -r
.@kit-ty-kate, I took me minimal docker file from one that you'd filed in an issue on the moby port, so it's presumably worked for you in the past?
The text was updated successfully, but these errors were encountered: