syslog error: No buffer space

[Kenn Kantola]

I am getting a message in syslog
Telnet/TCP:accept:No buffer space available.

I have not found a description of what this error message means. I would appreciate any information about this error message.

[Sridhar Bhaskarla]

This is the typical error that one of my applications was getting..

ENOBUFS - No buffer space available. Error No: 233.

Below is the explanation from the thread

http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0x286087dc4d7dd5118ff00090279cd0f9,00.html

//start

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.


//END

Does this help you?.

-Sri

[Vito Sarducci]

Kenn,

Try two things

1. I assume y have this problem with Oracle , try adding one more listner .

2. Go to the link
http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0x700aa22d6d27d5118fef0090279cd0f9,00.html
which essentially explains that :
when a new connect request arricves at the local tcp and it is immediately followed by a RESET from the remote system , the server application is awakened twice by the request to perform ( accept ( ) calls ) . Each is returned bu ENOBUFS or HP Error 233. The problem is the acceptin server application should not be awakened twice . This was caused by mishandling the connection id in the TPI messages . The problem is fixed by correctly tracking the connection id between the socket and TCP layers.

Also try loading the following patch PHNE_23456 to get more clues.

Try bufpages defines the number of 4096-byte memory pages in the file-system buffer cache.

See http://docs.hp.com/hpux/onlinedocs/os/KCparam.BufPages.html

HTH

Vito

[James Odak]

i believe i had this error as well on a 10.20 system .... try setting your buffpages to 0, this enables dynamic buffering, then set you dbc_max_pct and dbc_min_pct accordingly
10 and 5 percent accordingly is what we are set at.

[Kenn Kantola]

Vito, no I am not running Oracle. The error message appears to be related to telnet in, but I can't be sure. We run an Informix DB.
Sridhar, I am trying out the commands in the thread, but the netsat optins don't match so I am trying to find an equivelent that shows the detail. Thanks for the info.

[Brian Hackley]

Kenn,

There's a high probability that what is causing these messages is some host somewhere, connecting to the telnet TCP port, then disconnecting via RST immediately.

First try to enable connection logging with inetd e.g. inetd -l from the command line, you do this while inetd is running. The -l option is a "toggle switch" so if logging is off, it is turned on, and if it is on, it is turned off. You can run the command multiple times.

If that fails you will want to collect a sniffer and/or nettl trace on the system and watch those hosts conneting via telnet (TCP port 23) and determine if they are legitimate clients and also review these telnet conversations. You may need to engage a network specialist or consultant to assist you in this endeavor.

I recommend the above actions hoping that it helps you to track down a potential rogue or problem in your network.

Regards,

-> Brian Hackley

[Kenn Kantola]

Actually what I found was the nstrtel parameter was set a little too low. I increased this to a number above the telnet sessions I expect and the error went away.

Thanks for the suggestions.