[CRIU] checkpointing a docker container and restoring the process to a new container

[Ross Boucher]

Another update: I was intrigued by the exit code (which implies SIGPIPE?),
since the docker process I was running was indeed piping:

    /bin/sh -c 'i=0; while true; do echo $i; i=$(expr $i + 1); sleep 3;
done'

I tried the same process of checkpointing in one container and restoring to
another by writing to a file instead:

    /bin/sh -c 'i=0; while true; do echo $i > /tmp/foo; i=$(expr $i + 1);
sleep 3; done'
And this worked correctly! So I've narrowed it done some more, and I'll
continue to look into it.


On Thu, Apr 23, 2015 at 1:45 PM, Ross Boucher <rboucher at gmail.com> wrote:

> As a follow up, I tried manually editing the cgroup image file to swap the
> ID of the original container with the one I am restoring in, and the
> process still dies, so that probably isn't the issue.
>
> On Thu, Apr 23, 2015 at 1:21 PM, Ross Boucher <rboucher at gmail.com> wrote:
>
>> Hey everyone,
>>
>> I've gotten a bit further along in my project and run into a new issue.
>> Right now, to make my system work, I name my docker containers and keep
>> them around. But since they're all (essentially) identical, I'd like to
>> just delete them and create new ones as needed. So, I'm working on
>> checkpointing a container, and then later restoring the image files into a
>> new container.
>>
>> This seems to half work. Here's a dump and restore log from two separate
>> containers (I included the args sent to criu):
>>
>> dump: https://gist.github.com/boucher/9cc5a952a82c8f8b01b5
>> restore: https://gist.github.com/boucher/ffb6699353e01a09dff5
>>
>> Criu reports that the restore worked successfully, but after the restore
>> the new container/process immediately dies (the process itself is just a
>> simple bash script that echoes in a loop forever). No errors are printed
>> anywhere by docker or criu that I can find.
>>
>> The only information I have to go on right now is the exit code (141),
>> and the logs. My hunch is that it has to do with the cgroup info in the
>> image files, since the id of the original container (03cc978e3d29....) is
>> making its way into the restore log as well.
>>
>> I appreciate any suggestions. I'm going to be playing around with
>> --cgroup-root next to see if I can make that work.
>>
>> - Ross
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20150423/1860402c/attachment-0001.html>