[CRIU] Name resolved on unconnected socket

[Pavel Emelyanov]

On 02/24/2014 05:06 PM, Inti Gonzalez-Herrera wrote:
> I am wondering:
> Is it possible to write a plugin to handle such sockets? 

I think it's pretty possible to write a generic-level plugin for sockets,
so that one could provide callbacks for dumping and restoring sockets in
any states.

Thinking more about it, I think that it makes perfect sense to extend the
existing "ext-files" plugins, so that we have "layered" callbacks.

0. dump fd
1. `- dump generic fd
2.    `- dump generic inet socket
3.    `- dump generic unix socket
4.         `- dump external unix socket
5. `- dump external fd

Right now we have only 4 and 5, right now we can add 2 to let you handle
your case.

> I mean, I know the application won't use the sockets again, so I just want to discard them.

So it looks like you have a BUG in the application -- the socket never gets
closed, right?

> My question is: Will CRIU call the plugin list if it realizes that a socket "has a name but
> is unconnected"??? Or in a different way: Will CRIU call every single plugin before failing?
> 
> My idea of plugin is simple:
> DUMP
> 1 - Verify that the object is the file descriptor for a TCP socket
> 2 - Verify that the socket is in CLOSE_WAIT state
> 3 - Report success without recording the object as saved
> 
> RESTORE (Maybe I don't need this one since I don't recorded nothing in DUMP)
> 1 - Ignore the object
> 
> What do you thing? Just note that it only make sense if I know that such connections aren't waiting for nothing.
> 
> 
> 
> 
> On 24 February 2014 13:54, Cyrill Gorcunov <gorcunov at gmail.com <mailto:gorcunov at gmail.com>> 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?
> 
>     P.S. Please don't drop criu mailing list from email thread.
> 
>