moby: error removing container (1.10, 1.11/master) with AUFS
I’ve been seeing this error in our integration tests a lot recently:
Error response from daemon: 500 Internal Server Error: Driver aufs failed to remove root filesystem 36382c720964b0560df5fb858af8197169ee4eb399906c0e65c4ca85d795941e: rename /var/lib/docker/aufs/mnt/e7d36cc07ee4aad50f61259bea24876cc925f3c417b6d5ea9c2c1b055d243c82 /var/lib/docker/aufs/mnt/e7d36cc07ee4aad50f61259bea24876cc925f3c417b6d5ea9c2c1b055d243c82-removing: device or resource busy
This happens when a container is being removed and causes our tests to fail. I’ve seen it only on aufs so far.
Output of docker version
:
$ docker version
Client:
Version: 1.10.3
API version: 1.22
Go version: go1.5.3
Git commit: 20f81dd
Built: Thu Mar 10 15:54:52 2016
OS/Arch: linux/amd64
Server:
Version: 1.10.3-cs2
API version: 1.22
Go version: go1.5.3
Git commit: f02424d
Built: Thu Mar 17 21:52:14 2016
OS/Arch: linux/amd64
$ docker version
Client:
Version: 1.10.3
API version: 1.22
Go version: go1.5.3
Git commit: 20f81dd
Built: Thu Mar 10 15:54:52 2016
OS/Arch: linux/amd64
Server:
Version: 1.11.0-dev
API version: 1.24
Go version: go1.5.3
Git commit: dd94c88
Built: Thu Mar 31 21:32:39 2016
OS/Arch: linux/amd64
Additional environment details (AWS, VirtualBox, physical, etc.): This is happening on AWS with AUFS
Steps to reproduce the issue: unknown
Describe the results you received: 500 error from the daemon
Describe the results you expected: the container should be removed without an error
Additional information you deem important (e.g. issue happens only occasionally): It happens less than half of the time
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 12
- Comments: 79 (34 by maintainers)
I managed to reate this issue on 1.13 by doing the following:
At this point dockerd stop responding to http requests until I restarted the service
With dockerd restarted, I now get the following:
ERROR: Driver aufs failed to remove root filesystem
when trying docker-compose create
Same issue,
sudo service docker restart
fixed itIn case it helps anyone else, because I can’t upgrade Docker, the Kernel, or anything else on CircleCI, I’ve resorted to a simple daemon restart:
sudo service docker restart
Not really announced yet, but we also now have nightly builds in our apt/yum repository, e.g.: https://download.docker.com/linux/ubuntu/dists/xenial/pool/nightly/
@Puneeth-n I already did it, I even restarted my computer, but the container still there.
Do you have some link to instruct me how to change to
overlay2
?EDIT: I changed to
overlay2
, after restart the service the dead container is lost. All my images also, but I can pull it again.in between i stepped over to overlay2, this made me smile again 😃
Some light at the end of tunnel!
More experimentation yields some clues:
Given script finds PIDs that are related to Docker container path. Sometimes there are only couple of processes running (escaped from container?) and after killing them it is possible to remove container.
Other times, I see that most of processes (event init, pid 1) are related to container path. For example:
What we see in mountinfo?
I had same experience - but what @Puneeth-n suggested, upgrading linux kernel to 3.19.x seems to resolve this issue. No aufs errors since upgrade
I just saw this when trying to start a container using the
gcplog
logdriver that wasn’t able to launch successfully.I couldn’t find reference to that filesystem or any of those directories when groveling around in
/proc
or vialsof
.