10-21-2003 09:48 PM
inetd: ftp/tcp: accept: No buffer space available
Any suggestion ?
10-21-2003 09:53 PM
10-21-2003 09:55 PM
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 3072000 42236 3029764 1% 0 - 1 /dev/vgroot/lvol2
reserve - 1116748 -1116748
memory 1553780 953156 600624 61%
total 4625780 2112140 2513640 46% - 0 -
10-21-2003 10:05 PM
If that is the case, then try to add a buffersize when starting the ftpd by adding a -B option in /etc/inetd.conf for the ftp daemon. Set it to a small value. And when you're add it, also set logging to see if the message is generated immediately or after some time.
10-21-2003 10:07 PM
This is about accept() TCP procedure.What happens is that when server (ftp in your case) is busy client puts its request in a queue , later client timeouts but when server is free and tries to accept the connection RST bit is sent from the client ( I guess ) ,client buffers are freed from the server and server receives ENOBUFS from its TCP and complains.Ie, there was such an issue in Apache 1.x but was fixed in 2.x.What ftp server do you use, hp-ux usual?
10-21-2003 10:14 PM
It is not just FTP, there were few ocassions when telnet also reported same messages in the sylog.
The ftp version we use is 126.96.36.199
so whats the solution ?
10-21-2003 11:29 PM
you can find a lot of threads in this forum if you just search for "network " and "no buffer space".
Quickly glancing across them I found that on one occasion it was fixed by increasing the kernel parameter nstrtel, another fixed it by increasind maxdsiz.
Some indicate network patches, but you may want to take a closer look yourself.
10-21-2003 11:47 PM
Its hard to say since this message is general
regarding ENOBUFS (man accept). There were some applications that produced these messages and hanged. I think your case should be investigated, ie checking what applications are running, doing some network checks, etc. For example, you should check in syslog.log if there were another application messages before inetd reported this error.
10-22-2003 01:16 PM
Of course, some applications were not correctly treating ENOBUF as a transient error... :(
The only "fix" is to make sure the server application can get around to calling accept() in time - either by making the server application run faster, or by making the client more forgiving. Otherwise, unless it is happening a _lot_ or if apps are not correctly treating it as a transient condition, it can be safely ignored.