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.
Bug 1700883 - Impossible to recreate a container with the same name that a container already removed
Summary: Impossible to recreate a container with the same name that a container alread...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: podman
Version: 8.0
Hardware: All
OS: All
urgent
urgent
Target Milestone: rc
: 8.0
Assignee: Jindrich Novy
QA Contact: atomic-bugs@redhat.com
URL:
Whiteboard:
: 1703126 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-17 14:38 UTC by Emilien Macchi
Modified: 2020-11-03 20:51 UTC (History)
9 users (show)

Fixed In Version: podman-1.4.4 and newer in container-tools-2.0-8.2.0 and newer
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-19 15:36:06 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github containers libpod issues 2240 0 None closed Impossible to recreate a container with the same name that a container already removed 2020-10-19 15:14:26 UTC

Description Emilien Macchi 2019-04-17 14:38:48 UTC 
Description of problem:
Reported here: https://github.com/containers/libpod/issues/2240 by Hervé Beraud.

Version-Release number of selected component (if applicable):
podman-1.0.0-2.git921f98f.module+el8+2785+ff8a053f.x86_64

How reproducible:
A script launch the following command to start a container with the rm flag so the contianer will be destroyed at exit but when I try to recreate a container manually with the same podman command, podman fail to create the container and display the following error:

$ podman run --rm --name nova_cellv2_discover_hosts -it --label config_id=tripleo_step5 --label container_name=nova_cellv2_discover_hosts --label managed_by=paunch --net=host --user=root --volume=/etc/hosts:/etc/hosts:ro --volume=/etc/localtime:/etc/localtime:ro --volume=/etc/pki/ca-trust/extracted:/etc/pki/ca-trust/extracted:ro --volume=/etc/pki/ca-trust/source/anchors:/etc/pki/ca-trust/source/anchors:ro --volume=/etc/pki/tls/certs/ca-bundle.crt:/etc/pki/tls/certs/ca-bundle.crt:ro --volume=/etc/pki/tls/certs/ca-bundle.trust.crt:/etc/pki/tls/certs/ca-bundle.trust.crt:ro --volume=/etc/pki/tls/cert.pem:/etc/pki/tls/cert.pem:ro --volume=/dev/log:/dev/log --volume=/etc/ssh/ssh_known_hosts:/etc/ssh/ssh_known_hosts:ro --volume=/etc/puppet:/etc/puppet:ro --volume=/var/lib/config-data/nova_libvirt/etc/my.cnf.d/:/etc/my.cnf.d/:ro --volume=/var/lib/config-data/nova_libvirt/etc/nova/:/etc/nova/:ro --volume=/var/log/containers/nova:/var/log/nova --volume=/var/lib/docker-config-scripts/:/docker-config-scripts/ 192.168.122.1:5000/fedora-binary-nova-compute:ospsprint 
error creating container storage: the container name "nova_cellv2_discover_hosts" is already in use by "5efe2260d1aaadf63e8ce70d0aca100472bb0e0ee90884e95c785821a37d694c". You have to remove that container to be able to reuse that name.: that name is already in use
Comment 1 Daniel Walsh 2019-04-25 13:49:17 UTC 
Matt any update on this one?

This has high priority.
Comment 2 Matthew Heon 2019-04-25 14:10:52 UTC 
Per earlier diagnosis, what we're seeing appears to be Podman being run without /var/run mounted at some point, which obliterates c/storage and Podman local state as both assume a reboot has occurred. The most likely cause of this is Podman being run inside a container without /var/run mounted.

I don't believe we can reasonably recover from this. Correcting Podman's own state might be possible, but I don't think we can reconfigure the c/storage mount counter.

I think our best course of action is attempt to identify where Podman is being called without /var/run mounted and fixing that call. I'm going to land a patch upstream to log errors when Podman is run without /var/run mounted if /var/lib/containers or /var/lib/containers/storage is mounted into the container. We can modify the patch to turn logged errors into a hard fail, which should make it easier to identify where incorrect Podman calls are occurring.
Comment 3 Matthew Heon 2019-04-25 14:12:15 UTC 
(A further alternative would be attempting to convert all instances of Podman in a container to use podman-remote instead of mounting directories - it only requires mounting a single socket, as opposed to several directories, making it much more foolproof - but remote work is still incomplete in some areas so this is more of a long term solution)
Comment 4 Bernard Cafarelli 2019-04-25 16:44:28 UTC 
*** Bug 1703126 has been marked as a duplicate of this bug. ***
Comment 11 Daniel Walsh 2019-08-14 10:52:18 UTC 
Fixed in podman 1.4.4
Comment 15 Jindrich Novy 2020-10-19 15:22:16 UTC 
Emilien, based on comment #11 this got fixed in podman-1.4.4. If OpenStack uses container-tools-2.0-8.2.0 then it should be good as podman-1.6.4 is already there. Or do you still see related issue there?
Note You need to log in before you can comment on or make changes to this bug.