ports/66128: file descriptor leak in imapd from courier-imap-3.0.3,1

[David Wolfskill]

>Number:         66128
>Category:       ports
>Synopsis:       file descriptor leak in imapd from courier-imap-3.0.3,1
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-ports-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Apr 30 18:40:22 PDT 2004
>Closed-Date:
>Last-Modified:
>Originator:     David Wolfskill
>Release:        FreeBSD 4.8-RELEASE i386
>Organization:
Egation Communications
>Environment:
System: FreeBSD frhemail.colo.egation.com 4.8-RELEASE FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 root at freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/GENERIC i386

(Yes, I know the OS is a bit old.  But this didn't happen until
after we upgraded the ports a couple of weeks ago.)

%pkg_info -c courier\*
Information for courier-imap-3.0.3,1:

Comment:
IMAP (and POP3) server that provides access to Maildir mailboxes

One other point:  when I updated all the ports, I first installed
the lang/perl5 port (and did a "portupgrade -frR" on all the p5-*
ports) -- after a "use.perl port".  Thus:

%perl -v

This is perl, v5.6.1 built for i386-freebsd
....

>Description:
	Machine in question has become less-than-useful twice so far
	this week (once Monday morning; the next, Thursday afternoon);
	both times, the console had messages stating:

Apr 29 12:21:16 frhemail /kernel: file: table is full
Apr 29 12:21:16 frhemail last message repeated 4 times
Apr 29 12:23:49 frhemail last message repeated 13 times
Apr 29 12:29:13 frhemail last message repeated 60 times
Apr 29 12:29:13 frhemail syslogd: /dev/console: Too many open files in system: T
oo many open files in system

	So yesterday (Thursday) afternoon, I tried

		sysctl -a | grep files

	and found that kern.maxfiles was 12328 and kern.openfiles was at
	around 870.


	This morning (Friday), I started up a loop, doing the above
	every 5 minutes. Here is a salient excerpt:

		Fri Apr 30 17:35:48 PDT 2004
		kern.maxfiles: 12328
		kern.maxfilesperproc: 11095
		kern.openfiles: 3102
		p1003_1b.mapped_files: 0

		Fri Apr 30 17:40:48 PDT 2004
		kern.maxfiles: 12328
		kern.maxfilesperproc: 11095
		kern.openfiles: 3085
		p1003_1b.mapped_files: 0

		Fri Apr 30 17:45:48 PDT 2004
		kern.maxfiles: 12328
		kern.maxfilesperproc: 11095
		kern.openfiles: 3085
		p1003_1b.mapped_files: 0

		Fri Apr 30 17:50:48 PDT 2004
		kern.maxfiles: 12328
		kern.maxfilesperproc: 11095
		kern.openfiles: 3087
		p1003_1b.mapped_files: 0

		Fri Apr 30 17:55:48 PDT 2004
		kern.maxfiles: 12328
		kern.maxfilesperproc: 11095
		kern.openfiles: 139
		p1003_1b.mapped_files: 0

		Fri Apr 30 18:00:48 PDT 2004
		kern.maxfiles: 12328
		kern.maxfilesperproc: 11095
		kern.openfiles: 144
		p1003_1b.mapped_files: 0

	Note the sudden drop between 17:50:48 and 17:55:48 -- at
	17:54:13 I did a

		/usr/local/etc/rc.d/courier-imap-imapd.sh restart


	As a circumvention, I have created a crontab entry to perform
	such a restart daily, in the wee small hours of the morning.

>How-To-Repeat:
	Install and implement the imapd from courier-imap-3.0.3,1.  I
	suspect that the more frequently authentications are performed,
	the faster the file table will fill up.  That is no more than a
	hunch, though, and isn't even worth what you paid to read it.
>Fix:
	If I find one, I'll certainly updtae thi PR, if it's still open.
>Release-Note:
>Audit-Trail:
>Unformatted: