0

I have just been bitten by a PID file problem in a (Debian) Docker container that is configured as --restart always

Trying to summarize the problem:

  1. I start the apache2 service in my container. The init service creates a PID file in /var/run/apache2/apache2.pid
  2. I docker kill my container to simulate an improper shutdown of the host (electrical failure), the service gets ungracefully terminated, hence the PID file is still around.
  3. I start the container again (simulate host reboot), and try to start the apache2 service again. If the PID is reused (another program uses the PID httpd was runing with), then starting the service fails.

To properly start the service, I have to either:

  1. get lucky and the recycled PID is freed
  2. manually delete the PID file

Solution 1. is not a solution, obviously.

Solution 2. gets mentioned a lot, but is not a solution IMO because it involves doing that in either my entrypoint, or cmd, for EVERY service that I start in my container. And also have the knowledge that a specific image uses PID files, assumption that might not be true.

I can see a couple enhancements:

  1. /var/run is meant to be either volatile (tmpfs) or cleaned up at OS boot, so I could rm the whole content at container start (already better than removing specific PID files)
  2. Mount /var/run as tmpfs at container creation so that it gets cleaned up for me at container start

The tmpfs solution seems flawless to me (is it, really?), so I'm wondering if there is a systematic solution to apply it to all my container deployments (docker, docker compose, …), or if there is any drawback in applying it everytime? Because it seems to me as something I'll need to apply to ALL my container deployments, forever, and I don't want to have to do it explicitely, if possible.

Improve this question
6
  • 1
    Is there some reason why you are starting up the killed container, rather than creating a new one? Commented Jan 17, 2024 at 10:34
  • Using a tmpfs mount is a fine solution, but I agree with @bxm: you should treat the entire container as ephemeral, and simply start a new container rather than restarting an old one. Commented Jan 17, 2024 at 12:54
  • My use case is about having a long-running container, configured to restart with the host. If the host dies (e.g. electrical issue), my problem is occurring, because the not-tmpfs is dirty when the host (hence the container) restarts Commented Jan 17, 2024 at 13:00
  • so the docker kill/start was to simulate an unexpected host powercycle, clarified that in an edit Commented Jan 17, 2024 at 14:03
  • What is happening within the container that requires its reuse? If there is data you need to persist between runs, that is a problem you could solve with mounted volumes. Commented Jan 17, 2024 at 23:33

0

Reset to default

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.