Operating System - HP-UX
1834883 Members
2707 Online
110071 Solutions
New Discussion

Re: inetd[978]: telnet/tcp: accept: No buffer space available

 
Carol Clark
Advisor

inetd[978]: telnet/tcp: accept: No buffer space available

I have a customer who has been running our application successfully on a rp7400 hpux 11.00 for a number of years. Suddenly they have received the following error in the syslog file and it caused the database to freeze.

Could anyone please let me know what might have caused this ?
5 REPLIES 5
Robert-Jan Goossens_1
Honored Contributor

Re: inetd[978]: telnet/tcp: accept: No buffer space available

Hi,

Check this doc.

Title: Cannot telnet to serviceguard package ip, can ping it ok
Document ID: KBRC00004250

http://www4.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000080087907

Regards,
Robert-Jan
Carol Clark
Advisor

Re: inetd[978]: telnet/tcp: accept: No buffer space available

The nettl.LOG file has not been update since April
spex
Honored Contributor

Re: inetd[978]: telnet/tcp: accept: No buffer space available

rick jones
Honored Contributor

Re: inetd[978]: telnet/tcp: accept: No buffer space available

The last URL is a good one. I suspect it is spot-on (well, given that I posted something in that thread... :)

If the DB freezes on an ENOBUFS error on accept(), it is, frankly, broken as ENOBUFS is a _transient_ error not a fatal one. Of course, the ENOBUFS is being reported by _inetd_ which IIRC should be handling it just fine - that is the inetd shouldn't be locking up. Still, check for some inetd patches. And if inetd isn't locking-up (and I suspect it isn't) the DB still shouldn't be freezing.

Likely as not, over the years the load on the rp7400 has been steadily increasing until it finally went over the edge.
there is no rest for the wicked yet the virtuous have no pillows
Carol Clark
Advisor

Re: inetd[978]: telnet/tcp: accept: No buffer space available

Did'nt really get to the bottom of this although I suspect something happened on the Customers network that caused all the telnet sessions to disconnect abnormally. They were then able to connect that then caused the nrtrtel kernel parameter to be exceeded. The customer has not had the problem again to date !!!!!!