Kernel bug with UNIX sockets not detecting other end gone?

Kernel bug with UNIX sockets not detecting other end gone?

[Chris Evans]

Hi,

I wonder if the following is a bug? It certainly differs from FreeBSD 4.2
behaviour, which gives the behaviour I would expect.

The following program blocks indefinitely on Linux (2.2, 2.4 not tested).
Since the other end is clearly gone, I would expect some sort of error
condition. Indeed, FreeBSD gives ECONNRESET.

#include <sys/types.h>
#include <sys/socket.h>
#include <stdio.h>
#include <unistd.h>

int
main(int argc, const char* argv[])
{
  int the_sockets[2];
  int retval;
  char the_char;
  int opt = 1;

  retval = socketpair(PF_UNIX, SOCK_DGRAM, 0, the_sockets);
  if (retval != 0)
  {
    perror("socketpair");
    exit(1);
  }
  close(the_sockets[0]);
  /* Linux (2.2) blocks here; FreeBSD does not */
  retval = read(the_sockets[1], &the_char, sizeof(the_char));
}

Cheers
Chris

Re: Kernel bug with UNIX sockets not detecting other end gone?

[Alan Cox]

> The following program blocks indefinitely on Linux (2.2, 2.4 not tested).
> Since the other end is clearly gone, I would expect some sort of error
> condition. Indeed, FreeBSD gives ECONNRESET.

Since its a datagram socket Im not convinced thats a justifiable assumption.

Alan

Re: Kernel bug with UNIX sockets not detecting other end gone?

[Chris Evans]

On Thu, 17 May 2001, Alan Cox wrote:

> > The following program blocks indefinitely on Linux (2.2, 2.4 not tested).
> > Since the other end is clearly gone, I would expect some sort of error
> > condition. Indeed, FreeBSD gives ECONNRESET.
>
> Since its a datagram socket Im not convinced thats a justifiable assumption.

Hmm - there's definitely a Linux inconsistency here. With SOCK_DGRAM,
read() is blocking but write() is giving ECONNRESET.

The ECONNRESET makes sense to me (despite this being a datagram socket),
because the sockets are anonymous. Once one end goes away, the other end
is pretty useless.

Cheers
Chris

RE: Kernel bug with UNIX sockets not detecting other end gone?

[David Schwartz]

> Hmm - there's definitely a Linux inconsistency here. With SOCK_DGRAM,
> read() is blocking but write() is giving ECONNRESET.
>
> The ECONNRESET makes sense to me (despite this being a datagram socket),
> because the sockets are anonymous. Once one end goes away, the other end
> is pretty useless.
>
> Cheers
> Chris

	One can justify any behavior, since this is a datagram socket but the
kernel does know that it has been 'disconnected'. One can even justify the
inconcsistent behavior -- the write definitely has no place to go (now), but
the read can't be totally sure that there is no possible way anybody could
ever find the other end and write to it.	I think it would, however, be
preferable to have it return ECONNRESET in all cases (read, write, and
'select'/'poll' should hit on read and write).

	DS

Re: Kernel bug with UNIX sockets not detecting other end gone?

[Olaf Titz]

> kernel does know that it has been 'disconnected'. One can even justify the
> inconcsistent behavior -- the write definitely has no place to go (now), but
> the read can't be totally sure that there is no possible way anybody could
> ever find the other end and write to it.

For a socket created with socketpair()? I'm pretty sure there is no
way for any program to find any path to it, and if there is, it's a
kernel bug. Such a socket does not have a legitimate name. (And
getsockname() reliably returns garbage, which is another bug IMHO.)

Olaf

Re: Kernel bug with UNIX sockets not detecting other end gone?

[Kurt Roeckx]

On Thu, May 17, 2001 at 11:57:45PM +0100, Chris Evans wrote:
> 
> Hi,
> 
> I wonder if the following is a bug? It certainly differs from FreeBSD 4.2
> behaviour, which gives the behaviour I would expect.
> 
> The following program blocks indefinitely on Linux (2.2, 2.4 not tested).
> Since the other end is clearly gone, I would expect some sort of error
> condition. Indeed, FreeBSD gives ECONNRESET.

I'm having a simular problem, but somehow can't recreate it.

The difference is that I set the sockets to non-blocking, and
expect it to return some error.

read() returns 0, with errno set to 0, if the socket is still
open it returns -1 with errno set 11 (EAGAIN).  I can understand
those behaviours.

What I'm seeing however in an other program is that select says I
can read from the socket, and that read returns 0, with errno set
to EGAIN.  I call select() again, with returns and says I can read
from that socket ..., which keeps going on.  It stops from the
moment there is any i/o on an other socket.

Is there any way you can detect the other side is gone without
using write()?  write() shoud return an EPIPE.  Should I be able
to detect it with read(), or some oter system call?


Kurt

Re: Kernel bug with UNIX sockets not detecting other end gone?

[Alan Cox]

> What I'm seeing however in an other program is that select says I
> can read from the socket, and that read returns 0, with errno set
> to EGAIN.  I call select() again, with returns and says I can read

No no no. If the read does not return -1 it does not change errno. EOF isnt
an error.

Re: Kernel bug with UNIX sockets not detecting other end gone?

[Kurt Roeckx]

On Fri, May 18, 2001 at 09:02:51PM +0100, Alan Cox wrote:
> > What I'm seeing however in an other program is that select says I
> > can read from the socket, and that read returns 0, with errno set
> > to EGAIN.  I call select() again, with returns and says I can read
> 
> No no no. If the read does not return -1 it does not change errno. EOF isnt
> an error.

Of course, how stupid of me.


Kurt