SUMMARY: inetd: accept: Operation would block

From: A. Mahendra Rajah (Mahendra.Rajah@URegina.CA)
Date: Tue Apr 01 2003 - 11:30:38 EST


   I asked the following question a few days ago:

    ---------------------------------------------------------
    We could not telnet, ftp, ssh or LAT into our Alphaserver
    DS20 (Tru64 v5.1A + Pkit3) all day today. Xwindows
    connections worked.
 
    In the /var/adm/syslog.dated/daemon.log file and at the
    console, the following message got displayed frequently:

    <date> <machine> inetd[859]: accept: Operation would block
 
    What would cause this error to show up and why couldn't
    we make telnet, ssh or LAT connections to this host?
    ---------------------------------------------------------

   I received only one reply, from the ever reliable Dr. Tom
   Blinn. Tom said:

   If you read the accept(2) reference page, you will find
   this (or similar) text:

   [EWOULDBLOCK] The socket is marked nonblocking, and no
                 connections are present to be accepted.

   The standard string name for "EWOULDBLOCK" is "Operation
   would block"; if the current errno is the EWOULDBLOCK
   value and you use "perror()" to print an error string,
   you get that string.

   This is probably (but not necessarily) due to some
   resource inside the kernel being exhausted. After all,
   accept() becomes a syscall pretty quickly, and it's the
   kernel that returns the EWOULDBLOCK error code to the
   libc code, which returns it to the application. Either
   it's a bug in the kernel, or it's a predictable condition
   based on something that was happening in your network or
   your system at the time. Either way, that's about as
   much as I can tell you.. I can't tell you (without a
   close examination of the kernel code that get's invoked
   for an accept() which is NOT in my personal area of
   expertise) what condition causes the error to be
   returned; I could probably find someone who could point
   me to the right place in the IP stack to look, but it's
   not something I know particularly well..

   Thank you Tom.

   HP support pitched in and confirmed that this error was
   the remanant of some failed port scan attempt. Rebooting
   the machine cleared it.

   -- mahendra
.................................................................
   A. Mahendra Rajah Email: Mahendra.Rajah@URegina.CA
   Tru64 UNIX Systems Manager Phone: (306) 585-4496
   Dept. of Computing Services FAX: (306) 337-2324
   University of Regina,
   Regina, Sask., S4S 0A2
   Canada.
.................................................................



This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:14 EDT