[CRIU] File size is not same on restore

[Pavel Emelyanov]

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