<div dir="ltr">I can't reproduce it reliably, but it seems to happen about 10% of the time in my setup (though, there isn't a ton of data at this point). I can try to gather some more information for you if that would be helpful.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 16, 2015 at 2:30 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"><div class="HOEnZb"><div class="h5">On 07/16/2015 02:56 AM, Ross Boucher wrote:<br>
> I got this failure today when checkpointing a container in my system:<br>
><br>
> <a href="https://gist.github.com/boucher/ac5ac25c358e5a24665b" rel="noreferrer" target="_blank">https://gist.github.com/boucher/ac5ac25c358e5a24665b</a><br>
><br>
> Any idea what the cause might be?<br>
<br>
</div></div>Yup<br>
<br>
Error (sk-inet.c:188): Name resolved on unconnected socket<br>
<br>
We see reports about this from time to time. The error means, that there's<br>
some socket in the system, that is owned by a process (via fd), but while<br>
getting all the sockets via sock-diag API (in collect_sockets) this particular<br>
one was _not_ there. This happens only if the socket is freshly created with<br>
socket() call and is not yet bound or connected. The get_unconn_sk() function<br>
is called for such sockets -- found via some task's fd, but not found in diag<br>
output. We check that the socket in question is truly unbound and unconnected,<br>
but in your case the check fails.<br>
<br>
That's the best guess we have, but we cannot check one, since this situation<br>
occurs rarely. Do you know how to reproduce one more or less reliably?<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Pavel<br>
</font></span></blockquote></div><br></div>