Steven F Siirila
2007-Jan-24 20:14 UTC
[Dovecot] [sfs@tc.umn.edu: Re: dovecot-auth file descriptor usage]
I hate to be a pest, but are there any revelations on file descriptor "overusage" by dovecot-auth? ----- Forwarded message from Steven F Siirila <sfs at tc.umn.edu> ----- Date: Sat, 20 Jan 2007 12:42:50 -0600 From: Steven F Siirila <sfs at tc.umn.edu> To: Dovecot Mailing List <dovecot at dovecot.org> User-Agent: Mutt/1.4.2.1i Subject: Re: [Dovecot] dovecot-auth file descriptor usage Okay, here is one which has closed fds 0 and 1, so I presume it is proxying SSL: 11988: imap-login Current rlimit: unlimited file descriptors 2: S_IFIFO mode:0000 dev:295,0 ino:2692866 uid:0 gid:1 size:0 O_RDWR 4: S_IFCHR mode:0644 dev:287,0 ino:99614726 uid:0 gid:3 rdev:190,1 O_RDONLY|O_LARGEFILE FD_CLOEXEC /devices/pseudo/random at 0:urandom 5: S_IFIFO mode:0000 dev:295,0 ino:2692868 uid:65 gid:65 size:0 O_RDWR FD_CLOEXEC 6: S_IFIFO mode:0000 dev:295,0 ino:2692868 uid:65 gid:65 size:0 O_RDWR FD_CLOEXEC 7: S_IFSOCK mode:0666 dev:293,0 ino:33376 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(0.0.193.232) sockname: AF_INET 134.84.119.102 port: 143 peername: AF_INET 160.94.23.17 port: 38847 8: S_IFSOCK mode:0666 dev:293,0 ino:63591 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_SNDBUF(16384),SO_RCVBUF(5120) sockname: AF_UNIX peername: AF_UNIX default 9: S_IFSOCK mode:0666 dev:293,0 ino:43728 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_SNDBUF(16384),SO_RCVBUF(5120) sockname: AF_UNIX On Fri, Jan 19, 2007 at 11:34:44PM +0200, Timo Sirainen wrote:> On Wed, 2007-01-17 at 12:57 -0600, Steven F Siirila wrote: > > Doh! Here's another one (took 3 more trials to nab one): > > > > 29058: imap-login > > Current rlimit: unlimited file descriptors > > 0: S_IFSOCK mode:0666 dev:293,0 ino:63436 uid:0 gid:0 size:0 > > O_RDWR|O_NONBLOCK > > SOCK_STREAM > > SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.0.192.0) > > sockname: AF_INET 0.0.0.0 port: 143 > > 1: S_IFSOCK mode:0666 dev:293,0 ino:42189 uid:0 gid:0 size:0 > > O_RDWR|O_NONBLOCK > > SOCK_STREAM > > SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.0.192.0) > > sockname: AF_INET 0.0.0.0 port: 993 > > Almost, but not quite :) File descriptors 0 and 1 are open only when the > process is listening for new connections (for ports 143 and 993). So > this process wasn't proxying SSL. > > > 2: S_IFIFO mode:0000 dev:295,0 ino:2456463 uid:0 gid:1 size:0 > > O_RDWR > > This is logging pipe. > > > 3: S_IFSOCK mode:0666 dev:293,0 ino:37418 uid:0 gid:0 size:0 > > O_RDWR > > SOCK_STREAM > > SO_SNDBUF(16384),SO_RCVBUF(5120) > > sockname: AF_UNIX > > Connection to master process. > > > 4: S_IFCHR mode:0644 dev:287,0 ino:99614726 uid:0 gid:3 rdev:190,1 > > O_RDONLY|O_LARGEFILE FD_CLOEXEC > > /devices/pseudo/random at 0:urandom > > /dev/urandom. > > So it hasn't actually yet even connected to dovecot-auth.-- 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 ----- End forwarded message ----- -- 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
Timo Sirainen
2007-Jan-24 20:32 UTC
[Dovecot] [sfs@tc.umn.edu: Re: dovecot-auth file descriptor usage]
On Wed, 2007-01-24 at 14:14 -0600, Steven F Siirila wrote:> 8: S_IFSOCK mode:0666 dev:293,0 ino:63591 uid:0 gid:0 size:0 > O_RDWR|O_NONBLOCK > SOCK_STREAM > SO_SNDBUF(16384),SO_RCVBUF(5120) > sockname: AF_UNIX > peername: AF_UNIX defaultWell this is the authentication socket.> 9: S_IFSOCK mode:0666 dev:293,0 ino:43728 uid:0 gid:0 size:0 > O_RDWR|O_NONBLOCK > SOCK_STREAM > SO_SNDBUF(16384),SO_RCVBUF(5120) > sockname: AF_UNIXThis is a socket to master, but was it proxying yet? I think it should have said uid:<login process uid> if it was proxying.. Anyway I have tested this myself several times now, and it always closes it properly with me. I also don't see anything the code that could explain why it wouldn't close the connection. Have you tried if you're able to reproduce this in a test installation? If you can reproduce it and give me access to such a system where this happens, I could fix it then. -------------- 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/20070124/3ef49c92/attachment.bin>