Date: Mon, 7 Jun 2004 21:31:12 +0200 From: Arjan van Leeuwen <avleeuwen@piwebs.com> To: freebsd-current@freebsd.org Cc: "David A. Benfell" <benfell@parts-unknown.org> Subject: Re: file descripter leak in current with Qmail? Message-ID: <200406072131.14477.avleeuwen@piwebs.com> In-Reply-To: <Pine.NEB.3.96L.1040607125912.81780A-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1040607125912.81780A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Boundary-02=_CKMxApEJAcbkiOp Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, On Monday 07 June 2004 19:06, Robert Watson wrote: > On Mon, 7 Jun 2004, David A. Benfell wrote: (...) > > However, I think the more serious element here is the reason why you reach > the limit: this happens "naturally" under some workloads simply because of > large numbers of open files and network connections. However, in some > workloads, it's a symptom of a system or application bug, such as a > resource leak. > > Because the resources were returned when qmail was killed, that largely > eliminates the possibility of a kernel resource leak (not entirely, but > largely), as most kernel resource leaks involving file descriptors have > the symptom that even after the process exits, the resources aren't > release (i.e., a reference counting bug or race). This suggests a user > space issue -- that doesn't eliminate a system bug, as it could be a bug > in a library that manages descriptors, but it also suggests the > possibility of an application bug, or at least, a poor application > interaction with a system bug. Occasionally, we've seen bugs in the > threading libraries that result in leaked descriptors, but my recollection > is that qmail doesn't use threads. So that suggests either a support > library (perhaps crypto or the like), or qmail itself. Or that you just > hit an extremely high load. :-) > > In terms of debugging it: your first task it to identify if there's one > process that's holding all the fd's, or if it is distributed over many > proceses. After that, you want to track down what kind of fd is being > left open, which may help you track down why it's left open... Just as I'm reading this, I'm seeing the same thing on my -CURRENT server,= =20 which has a _very_ low load (atm, it's only routing the internet traffic fo= r=20 3 users and serving SMTP for 2 of them). I'm also running qmail. The kernel= =20 is from June 6. How do I go about investigating this further? Best regards, Arjan van Leeuwen --Boundary-02=_CKMxApEJAcbkiOp Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAxMKC3Ym57eNCXiERAgr6AKCpCl1RBjeRiFRLyIsAVcD+FNmXGACggU5Q 2FGfMyXMcSZbNRAjBAuntdk= =bOOd -----END PGP SIGNATURE----- --Boundary-02=_CKMxApEJAcbkiOp--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200406072131.14477.avleeuwen>