ENOBUFS ERROR

[Alexander Ongelico]

can anyone here help me with my problem. i am getting an ENOBUFS error with the accept function. what does this mean? what system resource is it referring to?

i have checked the internet and most info i get say that ENOBUFS occur in UDP writing to sockets and that it occurs when mbufs is exhausted. can anyone tell me what is this mbufs?

btw, i am working on a HP-UX HP Visualize 9000/785/B2000.

please advise me. thanks a lot.

[eran maor]

Hi

you can check the mbufs with :

/etc/netstat -T or tcpstat -T

and check the following parameters;

33/336 mbufs in use:
3/112 ( 80-byte) mbufs used/allocated
30/112 (1560-byte) mbufs used/allocated
0/112 (9216-byte) mbufs used/allocated
1187 Kbytes allocated to network (3% in use)
0 requests for memory denied


and you can read about the mbufs in this link :
http://www.docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B2355-90666/B2355-90666_top.html&con=/hpux/onlinedocs/B2355-90666/00/00/58-con.html&toc=/hpux/onlinedocs/B2355-90666/00/00/58-toc.html&searchterms=mbufs&queryid=20010724-031020


and you are rigth all the docs that i check is telling to check the zie of the mbufs .

also you need to install the 100bt patch ( if this the card taht you are working with )

[rick jones]

i am going to guess that you are running hp-ux 11. on that stack, it is possible for accept to return enobufs when the client side closes the connection before the server calls accept. enobufs was used instead of a new errno return from accept() because it already existed and was a non-fatal error. after an enobufs the linsten endpoint is still good and is still useable for incoming connections.

i suspect it has nothing to do with mbufs. in no small part because the HP-UX 11 networking stack does not use mbufs. it uses mblks :)

[Brian Hackley]

Hi,

This has been replied to previously.
Here's some technical details.

Regards,

-> Brian Hackley

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.