[CRIU] File size is not same on restore

[上司陽平]

On 11/10/15 21:52, Pavel Emelyanov wrote:
> On 11/10/2015 03:39 PM, 上司陽平 wrote:
>>
>> On 11/9/15 19:43, Pavel Emelyanov wrote:
>>> On 11/09/2015 01:39 PM, 上司陽平 wrote:
>>>> Thank you for replying but I can not solve this question...
>>>>
>>>>>> I succeeded to dump a lxc container but I can't restore it.
>>>>>>
>>>>>> A log of restore has following error messages:
>>>>>> (00.200896)    146: Error (files-reg.c:1078): File
>>>>>> lib/x86_64-linux-gnu/libcgmanager.so.0.0.0 has bad size 137024 (expect
>>>>>> 108480)
>>>>> This message means that at the restore time file's libcgmanager.so size
>>>>> is 137024.
>>>>>
>>>> Why is libcgmanager.so size 137024 at the restore time?
>>> I don't know, this is what stat system call reports on the path in question.
>>>
>>>> I checked a status on host OS,
>>>> $ stat /var/lib/lxc/u1/rootfs/lib/x86_64-linux-gnu/libcgmanager.so.0.0.0
>>>> This file's size is 108480.
>>>> Then I checked stat on the lxc container
>>>> $ stat /lib/x86_64-linux-gnu/libcgmanager.so.0.0.0
>>>> This file's size is 108480.
>>>> Therefore I think that libcgmanager.so size can not become 137024.
>>> Maybe upon start the file in question if over-mounted by something else?
>>> Try to find all libcgmanager.so.0.0.0 files in the root where you restore
>>> the container.
>>>
>>>> What is added to libcgmanager.so size?
>>>>
>>>> In addition, what should I do to solve this error problem?
>>> You can add debug info to criu so that it shows the inode and device number
>>> is stat()-s at open_path(). Then compare these numbers with the ones you
>>> check manually to make sure ciru and you work on the same file.
>> Thank you for your the advices. Pavel :)
>>
>> I checked the inode and device number where a process has an error.
>> These numbers are same as host's file.
>> (libcgmanager is 108480 in container's rootfs
>> [/var/lib/lxc/u1/rootfs/x86_64-linux-gnu/libcgmanager.so.0.0.0] and
>> libcgmanager is 137024 in host's root FS
>> [/x86_64-linux-gnu/libcgmanager.so.0.0.0])
>> Although the restoring process wanted to read container's rootfs, it
>> tried to read host's root FS.
>>
>> Does this mean that criu failed to set up namespace at the restore time?
> Not failed, but the caller didn't give it the correct --root option. Typically
> lxc does this, but if you launch criu restore by hands you should do it yourself.
>
> -- Pavel
I didn't declare --root option. When I set this option container's rootfs
[/var/lib/lxc/u1/rootfs], I faced the following error.

Path `/var/lib/lxc/u1/rootfs' resolved to `./' mountpoint
Error (mount.c:2727): New root and old root are the same

Would you please tell me how to decide a correct path?



I show the dump and restore options.

criu dump --skip-mnt /sys/kernel/debug/tracing -o dump.log
--tcp-established --file-locks --link-remap --force-irmap
--manage-cgroups -D ~/checkpoint --ext-mount-map auto
--enable-external-sharing --enable-external-masters
--enable-fs hugetlbfs -v4

criu restore -o restore.log
--tcp-established --file-locks --link-remap --force-irmap
--manage-cgroups -D ~/checkpoint --ext-mount-map auto
--enable-external-sharing --enable-external-masters
--enable-fs hugetlbfs -v4
--restore-detached --restore-sibling

Thanks,
Yohei Kamitsukasa