> > After upgrading to kernel 2.4.18pre7 (from 2.2.19), a recv() operation on
> > a UNIX socket returns 11 (EGAIN) even though the socket is blocking. My
> > code worked fine on 2.2.19.
> > I am doing some more debugging to see why this happens but I would like to
> > ask whether anyone else has had similar problems? Is this a known bug?
> Not a known one. A small test case would be good
The problem was caused when my code tried to read 0 bytes from a unix
socket (my fault, didn't specifically check for wanting to read 0 bytes,
assumed recv() would just return 0 ...).
When there is no data available, the code blocks. If, however, data is
available, recv() returns EGAIN. Is this correct behaviour? In kernel
2.2.19, recv() did in fact return 0;
Test example below.
int main(int argc, char *argv)
struct sockaddr_un server;
if (argc < 2)
printf("Usage : test socketname");
s = socket(PF_UNIX, SOCK_STREAM, 0);
if (s < 0)
server.sun_family = PF_LOCAL;
strncpy(server.sun_path, argv, sizeof(server.sun_path));
if (connect(s,(struct sockaddr *)&server,SUN_LEN(&server)) < 0)
retval = recv(s,buf,0, 0);
if (retval < 0)
printf("Received %u bytes.",retval);
St John's College, University of Cambridge, UK
Most people are good people, the rest of us are going to
run the world. -- badbytes
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/