【Docker】First aid when recreating a container and being scolded if you try to recreate it with the same container name as the one you deleted 【already in use by container】

4

【Event】

When creating a container operated in a test environment, the following message appeared. As for the flow, I was scolded when I stopped deleting the old container (test1) and recreated it again with the same container name (test1). It is an OK message if you change the container name at the time of creation, but the test environment that we are operating is an environment that also tests browser access etc. with the container name as a subdomain, so we can not afford to break the naming convention.

Furious Messages

[email protected] Server:~$ docker run -d -h test1 --name test1 -p 22 CountainerImage:Tag
docker: Error response from daemon: Conflict. The container name "/test1" is already in use by container 4f8893e6568ae9376e652a61ea2c64145c3cd3891aaacc092da83b4a68541c33. You have to remove (or rename) that container to be able to reuse that name..
See 'docker run --help'.

I'm really in conflict.... Since the container name is already in use, it is said that you should make the existing one an alias or something.

【Resolution】

As a first aid, I mv the file system mounted by the container and created it again with the same container name, and I was able to create it safely.

・ファイルシステムをmvしてみる。
[email protected] Server:~$ sudo mv /var/lib/docker/containers/4f8893e6568ae9376e652a61ea2c64145c3cd3891aaacc092da83b4a68541c33 /var/tmp/
・同じコンテナ名で再作成
[email protected] Server:~$ docker run -d -h test1 --name test1 -p 22 CountainerImage:Tag
→キマった

【What we checked before resolving the problem】

There are three things we checked before the first aid solution. 1. Confirm separation from SwarmOverLayNetwork 2. Check the proc of mount on the OS side 3. Confirmation of mistakes What scared me this time was that I did network isolation, docker stop, docker rm, and this message was spat out. I guess the demon is grasping it, but it was this message after 実は根元のホストも再起動...

:;(∩´﹏`∩);:

・Check SwarmOverLayNetwork  According to the investigation, troubles with containers composed of Swarm often occur when the daemon grabs it if it forgets to detach the container from the SwarmOverLayNetwork.  The network that was linked before the shutdown and deletion was (test).

ネットワークを確認
docker network inspect test | grep test1
→外れてい~る。

・ Is it mounted in the OS!? I rebooted once, but I wondered if the memory was grasping from the OS information.

cat /proc/mount| grep <該当コンテナのファイルシステム>
→いない。

- Mediocre mistake? Maybe you forgot to just stop and delete?

docker ps -a
いない

(ФДФ)

【What we tried before resolving the problem】

Some people solved it by unmounting the file system, so I tried to imitate it.

・手動でunmount
[email protected] Server:~$ sudo umount /var/lib/docker/containers/4f8893e6568ae9376e652a61ea2c64145c3cd3891aaacc092da83b4a68541c33
sudo: unable to resolve host HOST Server
umount: /var/lib/docker/containers/4f8893e6568ae9376e652a61ea2c64145c3cd3891aaacc092da83b4a68541c33: not mounted
→そんなファイルシステムはいないといわれる。

This time, I did a first aid in MV the file system, but if there is a real solution, please comment~.

【Details】

Docker Basics Webinar Q&A: Understanding Union Filesystems, Storage and Volumes https://blog.docker.com/2015/10/docker-basics-webinar-qa/ My own interpretation of docker's UnionFileSystem - See the Elephant https://namu-r21.hatenablog.com/entry/2016/10/27/013006

Share:
4
加藤 春樹
Author by

加藤 春樹

漫画とアニメが好きです。

Updated on December 13, 2018