Bug 1700883

Summary: Impossible to recreate a container with the same name that a container already removed
Product: Red Hat Enterprise Linux 8 Reporter: Emilien Macchi <emacchi>
Component: podmanAssignee: Jindrich Novy <jnovy>
Status: CLOSED CURRENTRELEASE QA Contact: atomic-bugs <atomic-bugs>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 8.0CC: atonner, bdobreli, chjones, dwalsh, jligon, jnovy, lsm5, mheon, tsweeney
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: 8.0   
Hardware: All   
OS: All   
Whiteboard:
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:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-10-19 15:36:06 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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?