Docker Community Forums

Share and learn in the Docker community.

Error get loopback backing file

docker

(Samanduck123) #1

Hi,
I can use systemctl inside docker container to start sshd. But, after I enable docker and run it, it gives the following error:

-- The result is failed.
Oct 06 13:41:01 8df56bc37658 systemd[1]: Unit docker-storage-setup.service entered failed state.
Oct 06 13:41:01 8df56bc37658 systemd[1]: docker-storage-setup.service failed.
Oct 06 13:41:01 8df56bc37658 systemd[1]: Starting Docker Application Container Engine...
-- Subject: Unit docker.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit docker.service has begun starting up.
Oct 06 13:41:02 8df56bc37658 docker-current[258]: time="2016-10-06T13:41:02.675411457Z" level=error msg="Error get loopback backing file: no such devic
Oct 06 13:41:02 8df56bc37658 docker-current[258]: time="2016-10-06T13:41:02.780639640Z" level=error msg="Error get loopback backing file: no such devic
Oct 06 13:41:02 8df56bc37658 docker-current[258]: time="2016-10-06T13:41:02.936629898Z" level=error msg="Error get loopback backing file: no such devic
Oct 06 13:41:03 8df56bc37658 docker-current[258]: time="2016-10-06T13:41:03.112603495Z" level=error msg="Error get loopback backing file: no such devic
Oct 06 13:41:03 8df56bc37658 docker-current[258]: time="2016-10-06T13:41:03.316634556Z" level=error msg="[graphdriver] prior storage driver \"devicemap
Oct 06 13:41:03 8df56bc37658 docker-current[258]: time="2016-10-06T13:41:03.316825805Z" level=fatal msg="Error starting daemon: error initializing grap
Oct 06 13:41:03 8df56bc37658 systemd[1]: docker.service: main process exited, code=exited, status=1/FAILURE
Oct 06 13:41:03 8df56bc37658 systemd[1]: Failed to start Docker Application Container Engine.
-- Subject: Unit docker.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit docker.service has failed.
-- 
-- The result is failed.
Oct 06 13:41:03 8df56bc37658 systemd[1]: Unit docker.service entered failed state.
Oct 06 13:41:03 8df56bc37658 systemd[1]: docker.service failed.
lines 1466-1492/1492 (END)

Please advise how I can solve this issue.


(David Maze) #2

You should probably do neither of these things. Use docker exec from the host to get a shell in a container. systemd has sprawling and invasive requirements and it’s not the best thing to run in a container. The container should just run your application directly (and not via a systemctl or service command: directly run the application daemon out of /usr/bin or wherever.)

So what’s happening here is that systemd inside your container is trying to start every single service that it would run on a real host system. It’s trying to start a new copy of Docker inside the Docker container! You almost definitely don’t want this; setting this up in a way that actually works is intricate (to the point where, even where there are legitimate uses for it, it’s tricky enough that nobody does it).

When you build your image you could probably do things like uninstall Docker or disable its systemd unit file or something else. But you’re better off not trying to run systemd at all.


(Samanduck123) #3

Thank you for the reply. But, how should I do it if I cannot run systemd. Let’s say I want a kubernetes master container and this container needs to start docker, sshd, kubernetes, kubectl with systemctl.
what is the way to achieve this?


(David Maze) #4

Not in a container! Probably a virtual machine. I’d use some sort of configuration management system (I’m partial to Ansible) to actually install the software. At a broad level, this sounds not totally unlike the setup I have that uses Terraform to provision AWS systems, then Ansible to get software on to it (which happens to include things that run in Docker). This also sounds like the sort of thing people talk about Vagrant for (I admit ignorance there).

Of the five things you listed, two (Docker and systemctl) are troublesome-to-difficult to run inside containers; a third (sshd) is considered poor practice; and I’m unfamiliar with Kubernetes beyond knowing that it’s generally something you’d use to orchestrate running containers elsewhere, so unless a normal deployment of it is to run some part of the system in a container, I’d also probably expect it to run on the host (or VM).

Also remember, best practice is generally to run only one process in a container, so if you did have a working Docker-in-Docker setup, the container would only run the Docker daemon and not any of the Kubernetes-related stuff.