[CRIU] I can't dump mysqld

[Yohei Kamitsukasa]

On 7/27/16 20:17, Dmitry Safonov wrote:

> On 07/27/2016 10:21 AM, uhoi wrote:
>> Hi, everyone.
>
> Hi,
>
>> I tried to dump mysqld, but I could not do so well.
>> I executed the followed command.
>>
>> criu dump -t mysqld_pid -D ${CHECKPOINT} -v4 -o dump.log --file-locks
>>
>> This command was not finished.
>> I think that criu stopped or did an infinite loop.
>> I can't find any errors in dump.log.
>>
>> I tried to set up my.cnf In reference to　https://lists.openvz.org
>> /pipermail/criu/2014-April/013425.html
>> and I turned off innodb_use_native_aio. However criu stopped...
>>
>> I can't understand what happened.
>> Please give me any advise...
>>
>> [dump.log]
> ...
>> (00.369533) Parasite syscall_ip at 0x400000
>> (00.369825) Set up parasite blob using memfd
>> (00.369833) Putting parasite blob into 0x7f2ec821f000->0x7f1ce412a000
>> (00.369854) Dumping GP/FPU registers for 8367
>> (00.369859) Warn  (arch/x86/crtools.c:132): Will restore 8367 with
>> interrupted system call
>> (00.369868) xsave runtime structure
>> (00.369871) -----------------------
>> (00.369874) cwd:37f swd:0 twd:0 fop:0 mxcsr:1fa0 mxcsr_mask:ffff
>> (00.369884) magic1:0 extended_size:0 xstate_bv:0 xstate_size:0
>> (00.369888) xstate_bv: 0
>> (00.369891) -----------------------
>> (00.369895) Putting tsock into pid 8367
>
> It looks like, criu is waiting for parasite in your application to
> establish connection on a socket. For some reason parasite does not
> finish that.
> We could get more info, if you do the following:
> $ cat /proc/${mysqld_pid}/stack
> $ cat /proc/${criu_pid}/stack
I appreciate your cooperation, Dmitry.
Oh, CRIU seems not to establish connection well as you said.

$ cat /proc/${mysqld_pid}/stack
[<ffffffff81221764>] poll_schedule_timeout+0x44/0x70
[<ffffffff81222e1f>] do_sys_poll+0x4af/0x560
[<ffffffff81223035>] SyS_poll+0xe5/0x130
[<ffffffff8182db32>] entry_SYSCALL_64_fastpath+0x16/0x71
[<ffffffffffffffff>] 0xffffffffffffffff

$ cat /proc/${criu_pid}/stack
[<ffffffff81715283>] __skb_recv_datagram+0x563/0x5c0
[<ffffffff8171531f>] skb_recv_datagram+0x3f/0x60
[<ffffffff817c69a1>] unix_accept+0x91/0x160
[<ffffffff817058a3>] SYSC_accept4+0x103/0x210
[<ffffffff81707490>] SyS_accept+0x10/0x20
[<ffffffff8182db32>] entry_SYSCALL_64_fastpath+0x16/0x71
[<ffffffffffffffff>] 0xffffffffffffffff

>
> Also it would be worth to know criu version (it looks like it's some
> from master branch, but we don't print exact version in logs yet).
I am using CRIU version: 2.0. (Ubuntu 16.04.1 LTS (GNU/Linux 
4.4.0-31-generic x86_64))

>
> I think to improve this kinds of faults, we could introduce another
> alarm in CRIU which would cure task and print error in case if the
> connection hasn't been established for some reson.
>
I use CRIU which is ubuntu package. (apt-get install criu)
Should I download criu source code and debug it by introducing another 
alarm in CRIU?