Vineet,
I have pasted the contents below.
11.0:accept() returns ENOBUFS(No buffer space available) DocId: WTECKBRC00005581 Updated: 9/26/02 5:23:00 AM
PROBLEM
From 11.0, application server - Informix / Oracle / inetd /
etc - sometimes causes "No buffer space available" or ENOBUFS.
This didn't happen on 10.X. Why does this happen and what can be
done to prevent this error?
RESOLUTION
How this symptom can be seen:
=============================
The symptom can be seen with any 'server' type application
which calls accept() system call. Inetd can also cause this
error on 11.0. Some customers see this with Informix / Oracle
and other major application's server daemon. The errno(see
man errno, for more details) is defined like:
#define ENOBUFS 233 /* No buffer space available */
in /usr/include/sys/errno.h. The way of printing this error
varies. Some application can just leave '233' in its log file.
Sophisticated application would call perror(3C) or
strerror(3C) to print the corrsponding error message(for
ENOBUFS, the message is "No buffer space available").
What ENOBUFS means:
===================
In many cases, ENOBUFS just means there's no sufficient
memory available and the system(kernel) can not allocate
any more. This is general definition and in most of case
such situtaion can be regarded as transient resource
shortage. And each system call can add some more information
in man pages if there're some specific meaning for each
error. Application will usually retry the operation when it
detects this error from a system call since it indicates
there's transient resource shortage.
When you look at accept(2), you will find the following
explanation:
[ENOBUFS] No buffer space is available. The accept() cannot
complete. The queued socket connect request is
aborted.
Why 11.0 accept() can cause ENOBUFS?
====================================
The description has not been changed at 11.0. However,
the implementation of accept() system call was changed
at 11.0(Transport stack has changed drastically due to
STREAMS based TCP/IP). And it can return -1 with
errno=ENOBUFS based on the condition of "the queued socket
connect request is aborted". Here, this means the transport
stack received RST just after SYN was received. If RST comes
before accept() is done, this situation can happen.
On 10.X, if this happens, the connection was just silently
dropped.
How this error should be handled?
==================================
If this can be seen with existing application, just ignore
the error. Since this can happen when we receive RST just
after SYN, the connection request is anyway cancelled.
There should be no serious problem.
If the application aborts with this error situation, it
should be re-written so that it will retry accept() system
call. ENOBUFS is usually indicating transient error. So,
aborting the application just by seeing this error once
should not be proper action. The application should be
modified so that it gets more robustness.
PORTABILITY ISSUE:
==================
UNIX Networking Programming Vol 1 Second Edition
(Richard Stevens, ISBN 0-13-490012-X) mentions this in
"5.11 Connection Abort before accept Returns" (page 129).
It says what happens is implementation dependent. HP-UX
11.0 returns ENOBUFS.
ALT KEYWORDS
Informix Oracle ENOBUFS
You may provide feedback here
