[CRIU] File size is not same on restore

[上司陽平]

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?

Thanks,
Yohei Kamitsukasa