Is it possible to take a snapshot of Container, but not image?


This is a use case: I have a container in which our major service process takes 10 mins to setup. I am wondering whether there is a way to take snapshot of the container (not just the file system, but also all processes status), and persist it somewhere, so I do not need to spend 10 mins every time the container is restarted.

I tried the Docker commit and load approach, but seems that it only persist file changes but not the process status.

Be honest, I am not sure whether this is a right thing to do or not. But just curious whether it can happen?

Looking forward to any suggestions. Please let me know if I do not explain my problem clearly.


You mention that you start up many processes in one container. Breaking those out into separate containers may be one way to shave time off of container start, and also architect your containers more appropriately: for a long time, the mantra has been “one process per container” (more like “one concern”, really, since some programs like Apache fork which is fine), and for mostly good reason: it saves you from conflating together a bunch of unrelated processes, and having to do things like restart your database when you only want to restart your app.

If you have really tried every hack on the books to get your container to boot faster (and maybe I’m being skeptical, but I find it hard to believe there isn’t any way you can speed up a ~10 minute start) and you’re still talking about such a long startup period, you have very few options left. And one of them is CRIU (checkpoint and restore in user space). Nothing else will restore all the contents of memory and so on from a running process, as you mention.

Now, some basic functionality to support checkpoint / restore has been added to Docker master, and it may actually land in 1.12, but it’s likely to be marked as “experimental” and only enabled if you explicitly opt-in. Not sure the current status of that.

That said, I’d give Docker master a whirl to see how you feel about it if you’re feeling ambitious. I’m not sure if the actual CLI has been implemented yet.


Would it be possible to share your Dockerfile? We’ll have a look and suggest improvements, if applicable.

  • Alexandre

Thank you so much for the detailed reply.

I totally agree with you that it would be the best if each container has one neat process. But the practical problem here is: this need-10-mins-setup entrypoint process is a 3rd-party process which I cannot and do not want to break into. You could imagine what a hassle to debug/refactor someone else’s codes. especially you are already know that the code is poorly written.

Regarding the new potential feature checkpoint/restore, I am quite looking forward to it. Instead of refactoring someone else’s code, I much prefer this solution.

Thanks for the help.

I will not brother you with the entire Dockerfile, since the problem is not in the Dockerfile, it is the entry-point process ( which take 10 mins to setup as below.


This entry-point process is 3rd-party and poor written, so this is the reason why I am looking for a snapshot of container instead of refactor the codes.

Aren’t you just offloading the problem to elsewhere though? By throwing CRIU into the mix you’re increasing surface area of possible bugs as well.

I’d look into invoking as part of your docker build and then invoking the final processes which need to be run directly in the final container.

7 java processes are created by the They have to be started (from corresponding jar files) in a certain order and with a certain amount of delay between them, this is the reason why it takes so long to finish. Regarding your suggestion that include as part of your docker build, maybe it is not suitable here because docker build would not save a Java process into an image. Please correct me if I am wrong.

Anyway, thank you so much for replying on such strange question. More I talk to you guys, more I think how important a simple and clear architecture is for containerization.