{"action":"created","issue":{"url":"https://api.github.com/repos/docker/docker/issues/10955","labels_url":"https://api.github.com/repos/docker/docker/issues/10955/labels{/name}","comments_url":"https://api.github.com/repos/docker/docker/issues/10955/comments","events_url":"https://api.github.com/repos/docker/docker/issues/10955/events","html_url":"https://github.com/docker/docker/issues/10955","id":58636940,"number":10955,"title":"docker rm succeeds even if underlying operations failed","user":{"login":"rhvgoyal","id":9487534,"avatar_url":"https://avatars.githubusercontent.com/u/9487534?v=3","gravatar_id":"","url":"https://api.github.com/users/rhvgoyal","html_url":"https://github.com/rhvgoyal","followers_url":"https://api.github.com/users/rhvgoyal/followers","following_url":"https://api.github.com/users/rhvgoyal/following{/other_user}","gists_url":"https://api.github.com/users/rhvgoyal/gists{/gist_id}","starred_url":"https://api.github.com/users/rhvgoyal/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rhvgoyal/subscriptions","organizations_url":"https://api.github.com/users/rhvgoyal/orgs","repos_url":"https://api.github.com/users/rhvgoyal/repos","events_url":"https://api.github.com/users/rhvgoyal/events{/privacy}","received_events_url":"https://api.github.com/users/rhvgoyal/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-02-23T19:40:42Z","updated_at":"2015-02-24T16:50:39Z","closed_at":null,"body":"Looks like docker rm does not care if any of the underlying operations needed to complete the remove operations succeeded or not. It goes on to remove the container anyway and leaving unrecoverable system resources if something failed.\r\n\r\nFor example, with device mapper backend, it can happen that device associated with rootfs of\r\ncontainer could not be removed. This can happen if device is busy. And device being busy can happen if somebody manually mounted the device somewhere else or for device mount point shows in some other process's namespace etc.\r\n\r\nBut docker removes the container from its data structures anyway. That means user can't see that container anymore in \"docker ps -a\" output. That means we left a device in device mapper thin pool which is consuming space in pool but we can't recover that space anymore.\r\n\r\nThis should be fixed. We should not remove container if any of the operations involved in removing\r\ncontainer fails. (I guess using --force should override this)."},"comment":{"url":"https://api.github.com/repos/docker/docker/issues/comments/75794564","html_url":"https://github.com/docker/docker/issues/10955#issuecomment-75794564","issue_url":"https://api.github.com/repos/docker/docker/issues/10955","id":75794564,"user":{"login":"rhvgoyal","id":9487534,"avatar_url":"https://avatars.githubusercontent.com/u/9487534?v=3","gravatar_id":"","url":"https://api.github.com/users/rhvgoyal","html_url":"https://github.com/rhvgoyal","followers_url":"https://api.github.com/users/rhvgoyal/followers","following_url":"https://api.github.com/users/rhvgoyal/following{/other_user}","gists_url":"https://api.github.com/users/rhvgoyal/gists{/gist_id}","starred_url":"https://api.github.com/users/rhvgoyal/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rhvgoyal/subscriptions","organizations_url":"https://api.github.com/users/rhvgoyal/orgs","repos_url":"https://api.github.com/users/rhvgoyal/repos","events_url":"https://api.github.com/users/rhvgoyal/events{/privacy}","received_events_url":"https://api.github.com/users/rhvgoyal/received_events","type":"User","site_admin":false},"created_at":"2015-02-24T16:50:39Z","updated_at":"2015-02-24T16:50:39Z","body":"Also if device removal fails then we leave /var/lib/docker/devicemapper/metadata/<container_id> file in there. This is like docker bloating its own metadata while there is no way to reference it from top. So not only we left some resources which should have been freed, we have some stale docker metadata too and I will never promote a user manually fiddling with docker metadata. \r\n\r\nKeeping that in mind, it makes sense to me to create a new container state to represent failed removal and allow user to try it later.\r\n\r\nIn fact we have forced removal optoin \"-f\". Right now this stops a running container before removing. May be in case of -f, we could always remove container even if there were errors releasing the resources held by container."}}