Buffer space

[jesudoss]

inetd[1062]: hacl-cfg/tcp: accept: No buffer space available Today i encountered this message from the syslog. Could any one please help me about this problem

[Steven E. Protter]

Shalom,

This is a problem with one of the service guard processes.

see that /etc/services is correct and the settings in inetd.conf are correct. Some modifications are required to make 11.16 SG work properly.

SEP

[jesudoss]

what are the service i have to look for. please assist me in detail and from the cluster what all i have to look

[skt_skt]

Did u check if u really had a swap/mem situiation at the same time?

[jesudoss]

Yes.I checked today at 7:00AM and i noticed this problem had occured at 5:00AM

Feb 4 00:31:02 uxetsk02 su: + tty?? root-tmax
Feb 4 05:04:25 uxetsk02 inetd[1062]: hacl-cfg/tcp: accept: No buffer space available
Feb 4 05:04:25 uxetsk02 inetd[1062]: hacl-cfg/tcp: accept: No buffer space available
Feb 4 05:05:00 uxetsk02 above message repeats 4 times

and this is the output of Top command

System: uxetsk02 Wed Feb 4 07:17:09 2009
Load averages: 0.03, 0.03, 0.03
557 processes: 519 sleeping, 37 running, 1 zombie
Cpu states:
CPU LOAD USER NICE SYS IDLE BLOCK SWAIT INTR SSYS
0 0.03 0.0% 0.0% 0.0% 100.0% 0.0% 0.0% 0.0% 0.0%
1 0.02 0.0% 0.0% 0.0% 100.0% 0.0% 0.0% 0.0% 0.0%
2 0.03 0.0% 0.0% 1.0% 99.0% 0.0% 0.0% 0.0% 0.0%
3 0.04 0.0% 0.0% 0.0% 100.0% 0.0% 0.0% 0.0% 0.0%
--- ---- ----- ----- ----- ----- ----- ----- ----- -----
avg 0.03 0.0% 0.0% 0.0% 100.0% 0.0% 0.0% 0.0% 0.0%

Memory: 7460080K (2353060K) real, 10377404K (4203316K) virtual, 122996K free Page# 1/13

and this is the output of machinfo -tam


CPU info:
Number of CPUs = 4
Clock speed = 1595 MHz
Bus speed = 532 MT/s
CPUID registers
vendor information = "GenuineIntel"
processor serial number = 0x0000000000000000
processor version info = 0x0000000020000704
architecture revision: 0
processor family: 32 Intel(R) Itanium 2 9000 series
processor model: 0 Intel(R) Itanium 2 9000 series
processor revision: 7 Stepping C2
largest CPUID reg: 4
processor capabilities = 0x0000000000000005
implements long branch: 1
implements 16-byte atomic operations: 1
Bus features
implemented = 0xbdf0000020000000
selected = 0x0000000000000000

Cache info (per core):
L1 Instruction: size = 16 KB, associativity = 4
L1 Data: size = 16 KB, associativity = 4
L2 Instruction: size = 1024 KB, associativity = 8
L2 Data: size = 256 KB, associativity = 8
L3 Unified: size = 9216 KB, associativity = 9

Memory = 16348 MB (15.964844 GB)

Firmware info:
Firmware revision = 02.03
FP SWA driver revision: 1.18
IPMI is supported on this system.
BMC version: 5.14

Platform info:
model string = "ia64 hp server rx6600"
machine id number = 832d8548-3541-11dc-a9f9-168d39dfddef
machine serial number = SGH4725MT2

OS info:
sysname = HP-UX
nodename = uxetsk02
release = B.11.23
version = U (unlimited-user license)
machine = ia64
idnumber = 2200798536
vmunix _release_version:
@(#) $Revision: vmunix: B11.23_LR FLAVOR=perf Fri Aug 29 22:35:38 PDT 2003 $

I hope this information is useful and please do assist me on this

[VK2COT]

Hello,

a) If your cluster is still fully operational,
check the usage of the server at the time when
maybe transient error was logged.

b) I hope your are running ServiceGuard
11.17 or above. This error was known to
happen on SG 11.16.

c) How old are your patches?
Set up Software Assistant and do the audit.
It takes five minutes to do it.

For example, patch PHSS_37608 deals with
some of buffer problems in SG 11.16.

d) Otherwise, check kernel usage. For
example:

# echo "bufpages/D" | adb -o /stand/vmunix /dev/kmem

# sysdef |grep bufpages

You might modify the dbc_max_pct and dbc_min_pct values in your kernel if
their values are not correct.

Cheers,

VK2COT

[rick jones]

Unless things have changed from olden days, 99 times out of 10 an ENOBUFS on an accept() simply means that by the time the application got around to calling accept(), the waiting client closed the connection.