Re: No buffer space available (3740 Views)
Reply
CBZ
Occasional Advisor
Posts: 10
Registered: ‎10-27-2009
Message 1 of 14 (3,740 Views)
Accepted Solution

No buffer space available


chargen/tcp: accept: No buffer space available
discard/tcp: accept: No buffer space available
daytime/tcp: accept: No buffer space available
ftp/tcp: accept: No buffer space available
swat/tcp: accept: No buffer space available
dtspc/tcp: accept: No buffer space available
printer/tcp: accept: No buffer space available
ident/tcp: accept: No buffer space available
exec/tcp: accept: No buffer space available
shell/tcp: accept: No buffer space available
login/tcp: accept: No buffer space available
telnet/tcp: accept: No buffer space available

Hi All,

Can any one please help me to understand why i am getting above mention error.

Thanks,
CBZ
Honored Contributor
Posts: 1,096
Registered: ‎09-12-2004
Message 2 of 14 (3,740 Views)

Re: No buffer space available

Honored Contributor
Posts: 2,246
Registered: ‎09-22-2008
Message 3 of 14 (3,740 Views)

Re: No buffer space available

can you post below output

/etc/rc.config.d/nddconf

Do you have lastest "Kernel RPC cumulative patch" ?

what os version ?
Problems are common to all, but attitude makes the difference
CBZ
Occasional Advisor
Posts: 10
Registered: ‎10-27-2009
Message 4 of 14 (3,740 Views)

Re: No buffer space available

# Example 1: Change the interval for sending the first keepalive probes
# for idle TCP connection to one hour
# TRANSPORT_NAME[0]=tcp
# NDD_NAME[0]=tcp_keepalive_interval
# NDD_VALUE[0]=3600000
#
#
# Example 2: Change the interval for sending keepalive probes to 1 minute
# when TCP is detached. (e.g.FIN_WAIT_2)
# TRANSPORT_NAME[1]=tcp
# NDD_NAME[1]=tcp_keepalive_detached_interval
# NDD_VALUE[1]=60000
#
#
# Example 3: Change the amount of time TCP endpoints persist in TIME_WAIT
# state to 30 seconds.
# TRANSPORT_NAME[2]=tcp
# NDD_NAME[2]=tcp_time_wait_interval
# NDD_VALUE[2]=30000
#
# Example 4: Change the UDP default ttl parameter to 128
# TRANSPORT_NAME[3]=udp
# NDD_NAME[3]=udp_def_ttl
# NDD_VALUE[3]=128
#
# Example 5: Change the amount of time that ARP entries can stay in
# ARP cache to 10 minutes.
#
# TRANSPORT_NAME[4]=arp
# NDD_NAME[4]=arp_cleanup_interval
# NDD_VALUE[4]=600000

HP-UX B.11.11 U 9000/800
Honored Contributor
Posts: 2,246
Registered: ‎09-22-2008
Message 5 of 14 (3,740 Views)

Re: No buffer space available

Suspect you need patch server
RPC cumulative patch ?
Contact with HP regarding the patches

can you post below values ?
do you have

dbc_min_pct =?
dbc_max_pct =?


Stop any application running (important)

add-in lines

TRANSPORT_NAME[n]=tcp
NDD_NAME[n]=tcp_conn_request_max
NDD_VALUE[n]=4096

NOTE: n = 0, 1, 2, 3, 4 ....
Problems are common to all, but attitude makes the difference
CBZ
Occasional Advisor
Posts: 10
Registered: ‎10-27-2009
Message 6 of 14 (3,740 Views)

Re: No buffer space available

Hi,

Thanks for your suggestions, could you please let me know from where i will get below info

dbc_min_pct =?
dbc_max_pct =?

Thanks
Honored Contributor
Posts: 2,246
Registered: ‎09-22-2008
Message 7 of 14 (3,740 Views)

Re: No buffer space available

what os version?

uname -a
Problems are common to all, but attitude makes the difference
CBZ
Occasional Advisor
Posts: 10
Registered: ‎10-27-2009
Message 8 of 14 (3,740 Views)

Re: No buffer space available

HP-UX B.11.11
Honored Contributor
Posts: 2,246
Registered: ‎09-22-2008
Message 9 of 14 (3,740 Views)

Re: No buffer space available

kmtune -q dbc_min_pct
kmtune -q dbc_max_pct
Problems are common to all, but attitude makes the difference
CBZ
Occasional Advisor
Posts: 10
Registered: ‎10-27-2009
Message 10 of 14 (3,740 Views)

Re: No buffer space available

Parameter: dbc_max_pct
Current: 20
Planned: 20
Default: 50
Minimum: -
Module: -
Version: -
Dynamic: No

Parameter: dbc_min_pct
Current: 5
Planned: 5
Default: 5
Minimum: -
Module: -
Version: -
Dynamic: No
Honored Contributor
Posts: 5,684
Registered: ‎08-05-2000
Message 11 of 14 (3,740 Views)

Re: No buffer space available

CBZ,

This has nothing to do with filesystem buffer cache (dbc_max_pct and dbc_min_pct) - it is simply a message telling you that when inetd tried to open sockets for these applications using the accept() system call, it returned an error code indicating "no buffer space available". This actually means that there is insufficient kernel memory available to create bufferes for these socket connections. These errors are usually transient and if you don't have a problem now can probably be ignored (all well behaved applications should re-try when they get ENOBUFS returned from accept() ). I'm sure Rick Jones can do a better job of explaining that than I can...

The fact you see the same message for a bunch of different ports in what looks (to me) like ascending order suggests that someone may be running a port scanner against this system - are you aware of anyone attempting that (e.g. using nmap or nessus or some other security scanning tool?)

HTH

Duncan

HTH

Duncan
Honored Contributor
Posts: 1,478
Registered: ‎01-23-2006
Message 12 of 14 (3,740 Views)

Re: No buffer space available

Seems to be related to high memory utilization as well, what is the memory utilization.

You may have to change various TCP parameters if some changes have been done your system recently.

BR,
Kapil+
I am in this small bowl, I wane see the real world......
CBZ
Occasional Advisor
Posts: 10
Registered: ‎10-27-2009
Message 13 of 14 (3,740 Views)

Re: No buffer space available

Thanks to all Super SAs....you \m/Rocks\m/
Honored Contributor
Posts: 3,814
Registered: ‎12-02-1996
Message 14 of 14 (3,740 Views)

Re: No buffer space available

What Duncan has said can be correct (BTW, while I see many Forum's postings, I don't see them all, and only chanced across this one) I'll repeat what was in the referenced entry from five years ago :)

99 times out of 10, a "No buffer space available" (aka ENOBUFS) on an accept() call means that by the time the server (again in this case inetd) got around to calling accept() on the listen endpoint, the remote end of the connection had given-up and gone away.

It means that your server was not keeping-up with the connection establishement rate.

Now, getting to the present, that they have appeared for all those services suggests that someone may have been bombarding your system with bogus connection requests - hardly anyone but crusty old network performance types :) connect to the chargen (character generator - spits-out a steady stream of bytes on the connection) or discard (bit buckets anything it is sent) services.

If your system is "external facing" on a (semi) public network you may want to look into disabling many of those services and doing other "hardening" things.

You can go into /etc/inetd.conf and disable chargen, discard and daytime straight away. You can *probably* disable ident. Some of the others will depend on whether or not you actually use those services on that server.
there is no rest for the wicked yet the virtuous have no pillows
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.