[CRIU] Name resolved on unconnected socket

[Pavel Emelyanov]

On 02/24/2014 04:54 PM, Cyrill Gorcunov wrote:
> On Mon, Feb 24, 2014 at 01:38:34PM +0100, Inti Gonzalez-Herrera wrote:
>>    Hi,
>>
>>    I am enclosing the output you asked me. Also, I tested the hypothesis
>>    about CLOSE_WAIT with two programs and it fail with the same message.
>>    Nevertheless, looking to the output you asked me I see  the error is on
>>    socket d9de (55774).
>>
>>    I executed lsof and I found this line
>>    java      4178   root    8u  IPv6  55774      0t0  TCP
>>    argos.irisa.fr:33329->isis.entimid.org:http (CLOSE_WAIT).
>>
>>    So, for me the problem is with CLOSE_WAIT. I was reading some information
>>    regarding this state and I am wondering if you avoid dumping because the
>>    process may be waiting some messages. Anyway, shouldn't CRIU close the
>>    connection anyway??? Maybe it is not a good idea in the general case, but
>>    it is a good idea to provide a flag for doing so. In my case, it seems
>>    that Java is not closing the connection until the collector is call it.
>>    Anyway, I am not sure since I don't have the source code of the
>>    middleware.
> 
> Well, as far as I know, yes. close-wait is not the state we can safely
> ignore. On the other hands restoring such socket in closed state is
> not hard. Pavel?

Well, CLOSE_WAIT state happens when the peer sends FIN to us, but "us" haven't
called close() yet. And for CRIU it's questionable whether it would happen ever,
so we should (in theory) handle it.

The problem is that in order to properly restore socket in such state we should
either patch the kernel's TCP repair engine, or send fake FIN packet to the freshly 
restored socket, via temporary raw socket. But the latter solution looks too hacky :)

And AFAIU the TCP state machine there's no way to workaround this by restoring the
socket in ESTABLISHED state. Neither can we restore the socket in CLOSED state.

> P.S. Please don't drop criu mailing list from email thread.

Thanks,
Pavel