The Vagrant Docker provider fails to stop Docker containers when using Sysbox #72
Comments
|
Another hint: I noticed that if I launch multiple sys containers with vagrant, and then destroy them, the destruction goes well for all but the last remaining sys container. In the prior comment I speculated on the shiftfs mount being the culprit, and this latest observation adds weight to that since shiftfs would only be unmounted when destroying the last remaining container. |
|
I also noticed another problem: when provisioning 16 sys containers with Vagrant (using the Docker provider with Sysbox), normally one of the containers fails to provision, with the following error: It seems that sysbox-runc is complaining that sysbox-mgr has taken too long to respond to a request issued via grpc. We need to investigate why sysbox-mgr is taking long enough to exceed the grpc deadline, and whether the grpc deadline is set correctly or should be increased. |
Playing around with Vagrant, I was easily able to create a container using the Docker provider + Sysbox. Here is the Vagrant file:
Running
vagrant upworks without problem.However,
vagrant haltorvagrant destroy -ffail with a cryptic error:I am not quite sure what's going on, but in Linux this type of error generally occurs when a command is executed from within a directory that no longer exists. That does not appear to be the case here, at least on the surface.
Speculating here: I noticed that when Vagrant runs the container, it mounts the Vagrant file in the host into the container's
/vagrantdirectory. This causes Sysbox to mountshiftfson the host directory where the Vagrant file is located. This in turn makes that directory non-exec. I wonder if this is playing a role somehow.Also: after the error occurs, the container is stopped but not removed. It must be removed explicitly with "docker rm".
The text was updated successfully, but these errors were encountered: