docker container won't start because an existing pid file
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.pidWhat 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.tartar -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.