docker 容器无法启动，因为现有的 pid 文件

Question

When I start a docker container it fails because an existing pid file:

[root@newhope sergio]# docker logs sharp_shockley 
httpd (pid 1) already running
httpd (pid 1) already running
httpd (pid 1) already running
httpd (pid 1) already running

How can I remove such a file, because I don't find it.

[root@newhope sergio]# docker version
Client version: 1.4.1
Client API version: 1.16
Go version (client): go1.3.3
Git commit (client): 5bc2ff8/1.4.1
OS/Arch (client): linux/amd64
Server version: 1.4.1
Server API version: 1.16
Go version (server): go1.3.3
Git commit (server): 5bc2ff8/1.4.1

[root@newhope sergio]# find / -name "httpd.pid"
find: ‘/run/user/1000/gvfs’: Permiso denegado

Answer 1

Try:

docker-compose down

To destroy any environments that are already running.

Answer 2

After way too much frustration, I solved this in my broke phabricator container:

You have to know what the name/path to the http pid file is. In the example below it's at /run/apache2/apache2.pid inside the container. Once you have that, you run the following:

docker start [container_id]; docker exec [container_id] rm /run/apache2/apache2.pid

What this does is start the container and then immediately tries to run the command to delete the PID file--hopefully before whatever process docker is supposed to start has time to fail. If your container process fails to quickly this might not work for you. Try running it a few times and you might beat it to the punch.

To find the location of my PID file, I did something similar to @sebelk, but instead of expanding the tar file I saved some time by just listing its contents and looking for the right filename...like so:

docker export [container_id] > /tmp/brokecontainercontents.tar
tar -tf /tmp/brokecontainercontents.tar | less 

This is silly, and there's probably a much better way to look through the contents of the container. Ideally you can find out the name of the PID file some other way (comments welcome!).

Epiphany

The answer above is useful, but I now realize that I and many others here have misunderstood Docker at a fundamental level. In fact, @styonsk's downvoted answer below is the correct one. And, @avijendr's critical comment of it is also correct: that will destroy data in the container--but it shouldn't matter. I'll explain.

I was originally told that Docker was "like chroot but better." That's truthy but misleading. In a chroot jail, your data lives inside the jail (of course it does, how else would the jailed process see it?). So when I started using Docker, I thought that the Volumes feature was a way to get at the data in the container--that you could mount the Volume to your local system and see what was in it. When I tried that I got really ticked off because it was as if the container LOST all my data--the container app acted that way, and there was nothing in the local mounted location! Wrong wrong wrong.

Volumes in Docker mount your local data/files into the container, not the other way around. So, when I mounted the volume to an empty local directory (expecting the files in the container to appear), instead the empty local directory was mounted into the container, hiding the files that existed in the container and making the app look like it had lost its data (well, because it had ). In reality, the fact that the Docker container even works without a Volume mounted is a side effect, and arguably a harmful one. That's not the way its intended to work. Any data that gets written to the Volume's location within the container is expected to be disposable!

(Incidentally, I started using Docker via Kitematic, which will pull, create, and start a container in one step without asking where you want to mount your Volumes , which is part of what gave me the wrong idea I think...I now personally believe it shouldn't start the container until you've mounted the Volumes somewhere or explicitly decided not to do so.)

So the intended use of a Docker container is usually (and should be) to run the application inside the container which acts on data outside the container, that is in the Volumes that are mounted through to your local system. That means that you should be able to just destroy the container if something goes wrong with it and start another copy mounted to the same Volumes--you get all your data back because it wasn't in the container in the first place.

Therefore, @styonsk's answer is the right answer: if you're using Docker correctly, you should just be able to destroy the container and fire up a new one. On the one hand this sounds like overkill, but on the other hand, the point of the containerized application is that you don't have to know what's going on inside it and arguably you don't...how do you know the only thing broken after an unclean shutdown is that the httpd.pid file is still there? There could be a lot more messed up that you don't know about! That's arguably what the abstraction is for.

If that model doesn't work for your use case--or you simply don't like it--the answer is probably that you shouldn't be using a Docker container. That's not a bad thing either, it's just that you may be trying to put a flathead screw in with a Phillips driver. You may just need a lightweight but full-stack VM environment instead.

Answer 3

Rebuilding/recreating might help. docker-compose up --build --force-recreate <service-name>

Also, the host (physical server) might have no disk space left.

Answer 4

Based on Paul's comment and docker documentation I've found the solution:

docker export sharp_shockley > /tmp/sharp_shockley.tar
mkdir /tmp/sharp_shockley
cd /tmp/sharp_shockley/
tar xvf sharp_shockley.tar
rm run/httpd/httpd.pid
rm sharp_shockley.tar
tar -c . | sudo docker import - apache3

Then I have to perform some minor fixes, remove temporary files on /var/run/httpd, commit the changes, and then I could start again my container.

More information at https://docs.docker.com/reference/commandline/cli/#import Docker Command Line

Answer 5

You shouldn't need to destroy the container. Since you didn't properly stop the container, there's still pieces hanging around. Specifically, the network is still connected to the container.

try: docker network list

You'll see something like:

NETWORK ID          NAME                             DRIVER              SCOPE
3d8f4b8ce4e5        bridge                           bridge              local
5ec8cb6bbe44        folderNameOfContainer_default    bridge              local
2503d2978229        host                             host                local

Then all you need to do is disconnect:

docker network disconnect folderNameOfContainer_default my_container_name

It's fine to docker-compose down too, but strictly speaking it isn't necessary.

Answer 6

我不是 Docker 专家，但是清除本地网站的容器的缓存可以解决问题。

Answer 7

somehow only down does not worked for me. Best solution for me so far was make a bash file like given below. tested many times myself it did the needed hack.

#!/usr/bin/env bash
# chmod +x start_dockers.sh
# ./start_dockers.sh

sudo docker-compose down

#stop all containers
sudo docker stop $(docker ps -aq)

sudo docker-compose up --build

Answer 8

This is a common issue occurs while running httpd as container,

• To avoid this error make sure the httpd runs in background(-D FOREGROUND),include below line in your Dockerfile for the same.

CMD ["/usr/sbin/httpd", "-D", "FOREGROUND"]

• Restart the docker and try again NB: stop all containers

• Is this issue occuring only after the commit? then follow the below steps,

1. Create docker file

2. Build the image

3. Run the container

4. stop the container

5. commit with the stopped container (id)

Thus the httpd process(pid 1) will not be running if the container is already stopped.