RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Description of problem:

Assume docker is using devicemapper graph driver. Say a container ran and exited. Try to run "docker rm <container>". If device removal or deactivation
failed for some reason (device was mounted in namespace of priviliged
container), then docker will give an error message but will still remove
the container from its data structures.

IOW, we have left resources behind and there is no easy way to remove
thin devices from pool and pool will never be able to recover that space.

So if underlying storage layer returns an error, don't ignore it and don't
remove container.

Version-Release number of selected component (if applicable):


How reproducible:

Always

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Opened an upstream issue to track this.

https://github.com/docker/docker/issues/10955

Sent a pull request with proposed fixes. Let us see if upstream takes it or not.

https://github.com/docker/docker/pull/11137

Got committed upstream. Fix should show up in 1.6.

commit 40945fc186067e5b7edd1f6cd7645ff2ae7cea6c
Author: Vivek Goyal <vgoyal>
Date:   Thu Mar 12 15:26:17 2015 -0400

    container: Do not remove contianer if any of the resource failed cleanup
    
    Do not remove container if any of the resource could not be cleaned up. We
    don't want to leak resources.
    
    Two new states have been created. RemovalInProgress and Dead. Once container
    is Dead, it can not be started/restarted. Dead container signifies the
    container where we tried to remove it but removal failed. User now needs to
    figure out what went wrong, corrent the situation and try cleanup again.
    
    RemovalInProgress signifies that container is already being removed. Only
    one removal can be in progress.
    
    Also, do not allow start of a container if it is already dead or removal is
    in progress.

Fixed in docker-1.6