[CRIU] [PATCH] zdtm: add a small program to create a zdtm container

[Christopher Covington]

On 08/13/2014 02:49 AM, Andrew Vagin wrote:
> On Tue, Aug 12, 2014 at 03:46:27PM -0400, Christopher Covington wrote:
>> On 08/12/2014 03:17 PM, Andrew Vagin wrote:
>>> On Tue, Aug 12, 2014 at 02:34:20PM -0400, Christopher Covington wrote:
>>>> Hi Andrey
>>>>
>>>> On 08/12/2014 12:13 PM, Andrey Vagin wrote:
>>>>> I didn't find a way how to do that with help "unshare".
>>>>> It's simpler to write this program. It looks better than tricks in
>>>>> zdtm.sh.
>>>>
>>>> How different is this from `criu restore -n mnt,pid,net,ipc`?
>>>
>>> I don't understand the question. This program is used to execute zdtm.sh
>>> in a container to avoid races between tests.
>>> The most popular race condition is when one test takes PID of another
>>> test, and the second test can't be restored.
>>
>> I guess I don't understand the -n, --namespace option to CRIU since I never
>> seemed to be able to get it to work. My intuition would be that it is supposed
>> to do the "interesting task" you describe below. Digging in to the matter, I
>> think I see why I've never gotten it to work:
>>
>> commit ac845bd1d8f7298e97b779f587a1fb46dd5737a7
>> Author: Pavel Emelyanov <xemul at parallels.com>
>> Date:   Thu Jan 17 18:14:55 2013 +0400
>>
>>     cr: Obsolete the --namespaces option
>>
>>     It's no longer required to use this option -- two currently
>>     supported cases (tasks on host and tasks in containers) can
>>     be detected automatically. Keep this option for future.
>>
>>> Maybe you mean that a test can be restored in a new pid namespace.
>>> Currently criu can't do that. Here is a few questions. Who will be
>>> the init process? The root task probably doesn't ready to be a sub-reaper.
>>> Do we need to remount /proc? If the answer is yes, we need to create
>>> a new mount namespace together with pidns.
>>> I think this is interesting task, which will be one day implemented.
>>
>> Why not simply move the contents of test/zdtm_ct.c into crtools.c, executed
>> conditionally based on -n, --namespace, and call it initially implemented?
> 
> Personally I'm not sure that we need this. Each one can execute "unshare"
> and setup a container how he wants. Then he/she executes "criu restore"
> and has the expected result.

I have read that `unshare` is insufficient in some cases.

>>>> On 08/12/2014 12:13 PM, Andrey Vagin wrote:
>>>>> I didn't find a way how to do that with help "unshare".
>>>>> It's simpler to write this program. It looks better than tricks in
>>>>> zdtm.sh.

> If you look at zdtm_ct, you can find that it mounts /dev/pts. I'm not
> sure, that each one will want to do that.

I meant to suggest that it would be optional, and probably off by default, so
that those who might object to such (seemingly reasonable) steps can have full
flexibility. On the other hand, those who just want to checkpoint and restore
a process easily can turn it on. If the steps work for the test suite, isn't
that proof that they are applicable to a diverse set of applications?

> I'm afraid if we will apply needs of all users, in a one moment we will
> have another lxc in the CRIU source.

I'm not familiar with LXC, but if it is the best way to set up such
containers, why not call it instead?

Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.