When using a function like fpAccept on a non-blocking socket, in some cases -1 is returned with a documented (Linux kernel) error code of EAGAIN. Should I be looking for this in errno or SocketError?

When I've retrieved a numeric code from errno or SocketError, is there a way of converting it to a concise literal such as 'EAGAIN'? I want the log to report that accept() has failed with EAGAIN, rather than having explanatory text that doesn't match the kernel documentation.

In our previous episode, Mark Morgan Lloyd said:

When using a function like fpAccept on a non-blocking socket, in some cases -1 is returned with a documented (Linux kernel) error code of EAGAIN. Should I be looking for this in errno or SocketError?

Socketerror is more portable, but on *nix errno will work too.

When I've retrieved a numeric code from errno or SocketError, is there a way of converting it to a concise literal such as 'EAGAIN'?

See errors unit.

I want the log to report that accept() has failed with EAGAIN, rather than having explanatory text that doesn't match the kernel documentation.

EAGAIN generally means that you should try again. So repeat until

  repeat
    res:=dofunc;
    err:=geterrno;
  until (res-1) or ((errESysEINTR) and (errESysEAgain));

it is a workaround against potential deadlock between userland and kernel iirc. Retrying means it can simple work.

Thanks, found that in the source.

> When I've retrieved a numeric code from errno or SocketError, is there a > way of converting it to a concise literal such as 'EAGAIN'? See errors unit.

But if I'm reading that properly, it translates (some OS-specific number) to 'Try again', not to 'EAGAIN' which is what the kernel docs refer to and which can reasonably be logged without requiring i18n.

> I want the > log to report that accept() has failed with EAGAIN, rather than having > explanatory text that doesn't match the kernel documentation.

should there be some sort of retry count or timing period in which to decide to give up so that one doesn't retry forever? if yes, how might that be accomplished? ;)

admittedly, i may have missed something in the ESysEINTR and ESysAgain portion since i'm a new babe with regards to signaling like that... but i just had to ask, ya know? ;)

In my case I've set the sockets non-blocking and am polling non-destructively until a complete request has arrived (I'm writing a custom finger daemon, so expect \r\n). After a minute the socket gets moved to a different list to be tarpitted, or if that can't be done to be held open for a few minutes to discourage casual hackers. Detail debugging continues, but I'm trying to be very aggressive against abusers since it will be giving out temporary passwords for database connection.