Date: Mon, 28 Feb 2000 10:37:11 -0500 From: James FitzGibbon <james@targetnet.com> To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org Subject: How to rememdy ENOBUFS return from socket(2) ? Message-ID: <20000228103711.B10570@targetnet.com>
next in thread | raw e-mail | index | archive | help
I'm noticing that on my 3.4-STABLE system, socket(2) is returning ENOBUFS rather often, causing obvious problems. The application in question is trying to create an AF_INET|AF_LOCAL socket. From looking through the kernel source I've deduced that soalloc() is failing because zialloc can't get space in the "socket_zone". I also found the place where that zone is initialized to the max of "maxfiles" and "nmbclusters". The present value of maxsockets on this box is 16424 (the value of "NMBCLUSTERS" in my kernel config. The relevant kernel config lines are: maxusers 768 options "NMBCLUSTERS=16384" options "NBUF=2048" My question is: if the system is running out of space in this zone, should I be tweaking kern.ipc.maxsockets using sysctl, or trying to hunt down whatever errant process is sucking up the zone ? Two related questions: - will tweaking kern.ipc.maxsockets after the system is up do anything ? The value seems to be used in uipc_socket2.c in calls related to SYSINIT, so I presume that it is only referenced during system startup. - if an long-lived application never calls close() on it's sockets, would that eventually cause this problem for all applications across the board, or just that one application (i.e. is there a per-process socket maximum or just a system-wide one) ? TIA for any help. -- j. James FitzGibbon james@targetnet.com Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000228103711.B10570>