<div dir="ltr"><div><div><div>Thanks a lot, Pavel! <br>I think this was the problem :)<br></div><div></div></div><br>Thanks for the great work on CRIU!<br><br></div>Fred<br><div><div><br><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 6, 2014 at 6:24 AM, Pavel Emelyanov <span dir="ltr"><<a href="mailto:xemul@parallels.com" target="_blank">xemul@parallels.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/06/2014 02:12 AM, Frederico Araujo wrote:<br>
> Dear list,<br>
><br>
> I've notice that sometimes checkpoint fails with the following error (please see attached log):<br>
><br>
</span>> /Error (sk-tcp.c:66): Can't turn TCP repair mode ON: Operation not permitted/<br>
<span class="">><br>
> However, I'm executing criu as sudo. Could it be that the file descriptor for the socket being<br>
> dumped is set as RO or immutable? In which cases this error would occur?<br>
<br>
</span>It also happens if the socket we're turning repair on is not in closed/established<br>
state. Since this error happens not every time, I think I know why this happens.<br>
<br>
The TCP socket dump goes in 3 steps<br>
<br>
1. collect<br>
<br>
Here we talk to kernel's tcp_diag subsys fetching the info about tcp sockets.<br>
At this stage we get the state the socket is in and next two steps only occur<br>
if the state is closed/established.<br>
<br>
2. lock<br>
<br>
Here we block the packets with netfilter<br>
<br>
3. dump<br>
<br>
Here we turn repair on and get the socket state into image file<br>
<br>
<br>
So, if between steps 1 and 2 the FIN packet arrives the socket would get turned<br>
into one of the closing states and we will fail to turn repair ON on it.<br>
<br>
Thanks,<br>
Pavel<br>
<br>
</blockquote></div><br></div>