Re: [Dovecot] dovecot-auth file descriptor usage
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..
On Wed, Jan 17, 2007 at 12:48:53AM +0200, Timo Sirainen wrote:
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 :)
I realize that, but in an environment where there are thousands of IMAP connections (our UW-IMAP servers) we expect to need more login processes standing by.
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..
I was able to get one by doing the following:
set login_process_count = 1 and restart dovecot
Determine pid of the one imap-login above (pid 25814)
Truss -f that process, waiting for the first child process to start, and extract the pid of that process, and run "pfiles" on that pid:
( truss -f -p 25814 | & fgrep -v 25814: | head -1 | sed -e 's/:.*//' -e 's/^/pfiles /' > x ) ; sh -x x > pfiles.out
The contents of the pfiles.out file is:
26738: imap Current rlimit: unlimited file descriptors 0: S_IFSOCK mode:0666 dev:293,0 ino:39965 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_SNDBUF(16384),SO_RCVBUF(5120) sockname: AF_UNIX 1: S_IFSOCK mode:0666 dev:293,0 ino:39965 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_SNDBUF(16384),SO_RCVBUF(5120) sockname: AF_UNIX 2: S_IFIFO mode:0000 dev:295,0 ino:2453883 uid:0 gid:1 size:0 O_RDWR 3: 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@0:urandom 4: S_IFIFO mode:0000 dev:295,0 ino:2453884 uid:133702 gid:1000 size:0 O_RDWR FD_CLOEXEC 5: S_IFIFO mode:0000 dev:295,0 ino:2453884 uid:133702 gid:1000 size:0 O_RDWR FD_CLOEXEC 6: S_IFREG mode:0600 dev:85,53 ino:17665 uid:133702 gid:1000 size:3176 O_RDWR|O_LARGEFILE /home/xxxxxxxx/.imap/INBOX/dovecot.index 7: S_IFREG mode:0600 dev:85,53 ino:17798 uid:133702 gid:1000 size:89704 O_RDWR|O_LARGEFILE /home/xxxxxxxx/.imap/INBOX/dovecot.index.log
If an lsof is required, I'll have to look into compiling one for Solaris 10.
--
Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: sfs@umn.edu Office of Information Technology Voice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
On Wed, 2007-01-17 at 12:50 -0600, Steven F Siirila wrote:
- set login_process_count = 1 and restart dovecot
- Determine pid of the one imap-login above (pid 25814)
- Truss -f that process, waiting for the first child process to start, and extract the pid of that process, and run "pfiles" on that pid:
( truss -f -p 25814 | & fgrep -v 25814: | head -1 | sed -e 's/:.*//' -e 's/^/pfiles /' > x ) ; sh -x x > pfiles.out
The contents of the pfiles.out file is:
26738: imap
I guess something went wrong, because this is from a different PID and from an imap process, not imap-login :)
On Wed, Jan 17, 2007 at 08:54:53PM +0200, Timo Sirainen wrote:
On Wed, 2007-01-17 at 12:50 -0600, Steven F Siirila wrote:
- set login_process_count = 1 and restart dovecot
- Determine pid of the one imap-login above (pid 25814)
- Truss -f that process, waiting for the first child process to start, and extract the pid of that process, and run "pfiles" on that pid:
( truss -f -p 25814 | & fgrep -v 25814: | head -1 | sed -e 's/:.*//' -e 's/^/pfiles /' > x ) ; sh -x x > pfiles.out
The contents of the pfiles.out file is:
26738: imap
I guess something went wrong, because this is from a different PID and from an imap process, not imap-login :)
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 2: S_IFIFO mode:0000 dev:295,0 ino:2456463 uid:0 gid:1 size:0 O_RDWR 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 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@0:urandom
--
Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: sfs@umn.edu Office of Information Technology Voice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
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@0:urandom
/dev/urandom.
So it hasn't actually yet even connected to dovecot-auth.
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@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@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@umn.edu Office of Information Technology Voice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
participants (2)
-
Steven F Siirila
-
Timo Sirainen