In dovecot-auth (rc15) we experienced problems when the file descriptors reached 256 (due to a Solaris fdopen() call described previously). The issue was that there was one file descriptor being used for every imap-login and pop3-login process (in our environment of SSL-only that means one for every active IMAP and POP connection). Mods were made (and appear in rc16) to close out the descriptor in question after using it during authentication (as I understand it). However, I am still seeing plenty of file descriptors left open in rc16 (one per session). For example, on a Solaris 9 server with 9 IMAP connections open here is an lsof excerpt of dovecot-auth: dovecot-a 26071 root 7u unix 105,136 0t79 3190 /devices/pseudo/tl at 0:ticots->/var/opt/dovecot/run/dovecot/login/default (0x3000d084250) dovecot-a 26071 root 8u unix 105,140 0t80 3190 /devices/pseudo/tl at 0:ticots->/var/opt/dovecot/run/dovecot/login/default (0x3c9c4227b68) dovecot-a 26071 root 9u unix 105,149 0t79 3190 /devices/pseudo/tl at 0:ticots->/var/opt/dovecot/run/dovecot/login/default (0x3cbaa7680b8) dovecot-a 26071 root 10u unix 105,266 0t79 3190 /devices/pseudo/tl at 0:ticots->/var/opt/dovecot/run/dovecot/login/default (0x3cbaa765d48) dovecot-a 26071 root 11u unix 105,160 0t79 3190 /devices/pseudo/tl at 0:ticots->/var/opt/dovecot/run/dovecot/login/default (0x3cbaa7667e0) dovecot-a 26071 root 12u unix 105,255 0t79 3190 /devices/pseudo/tl at 0:ticots->/var/opt/dovecot/run/dovecot/login/default (0x3cbaa769288) dovecot-a 26071 root 13r DOOR 265,0 0t0 50 /var/run (swap) (door to nscd[7752]) dovecot-a 26071 root 14u unix 105,258 0t79 3190 /devices/pseudo/tl at 0:ticots->/var/opt/dovecot/run/dovecot/login/default (0x30002dc4008) dovecot-a 26071 root 15u unix 105,282 0t80 3190 /devices/pseudo/tl at 0:ticots->/var/opt/dovecot/run/dovecot/login/default (0x30003185738) dovecot-a 26071 root 16u unix 105,141 0t80 3190 /devices/pseudo/tl at 0:ticots->/var/opt/dovecot/run/dovecot/login/default (0x30003185ac8) With the modification made, shouldn't these no longer accumulate? -- Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: sfs at umn.edu Office of Information Technology Voice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
On Fri, 2007-01-05 at 13:55 -0600, Steven F Siirila wrote:> Mods were made (and appear in rc16) to close out the descriptor in question > after using it during authentication (as I understand it). However, I am > still seeing plenty of file descriptors left open in rc16 (one per session). > For example, on a Solaris 9 server with 9 IMAP connections open here is > an lsof excerpt of dovecot-auth:How about if you check those imap-login processes that are doing only SSL proxying, do they also have the socket open? I just tried myself, and dovecot-auth keeps only as many auth sockets open as there are imap-login processes accepting new connections.. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070117/d1a7b644/attachment.bin>
On Tue, 2007-01-16 at 16:33 -0600, Steven F Siirila wrote:> > I'm now just wondering if it's only dovecot-auth that doesn't notice the > > socket closing for some reason, or if the imap-login processes proxying > > SSL didn't really close the socket after all. > > I have attached our dovecot.conf and a "pfiles" (like lsof) output of > dovecot-auth, showing all of its open file descriptors. I hope this helps. > If there is anything else I can provide to shed more light, let me know.login_processes_count = 32 This means that Dovecot always keeps extra 32 login processes that don't do anything else than wait for new connections. That's not at least helping :) Anyway, I'd like to get lsof of an imap-login process that is doing SSL proxying. Unfortunately I don't think there's any simple way to know what processes are doing that and what aren't. Setting login_process_count=1 at least makes it more likely that you'll hit the right process. If trussing the process shows that it's writing some garbage to file descriptor 1, it's probably proxying SSL.. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070117/238d81b1/attachment.bin>