On Tuesday, March 11, 2003, at 01:40 PM, Sebastian Hagedorn wrote:
-- Jon Rowell <[EMAIL PROTECTED]> is rumored to have mumbled on Dienstag, 11. März 2003 12:24 Uhr -0600 regarding Re: delayed response from pop3d:
On Friday, March 7, 2003, at 12:40 PM, Rob Siemborski wrote:
On Fri, 7 Mar 2003, Jon Rowell wrote:
Since the upgrade, I am getting a delayed response from my pop3d. I
have pop3 running on port 10110 and imap running on 10443 (as stated
in
cyrus.conf). If I startup master and then do "telnet localhost 10110"
I get the usual telnet stuff about "connected to localhost" and
"Escape
character" but instead of getting the usual "+OK hostname Cyrus POP3
v2.1.12 server ready ..." stuff it just sits there. The greeting
message does come up but it takes 5 minutes. After the greeting comes
up, the server works fine.
Imap appears to work fine. There is a split second delay that I don't
remember being there but otherwise it is fine.
Run the strace/truss equivilant on the processes and see whats taking them so long.
Offhand, it sounds like a /dev/random problem (not enough entropy), in
which case the solution is to link /dev/urandom to /dev/random.
Linking /dev/random to /dev/urandom fixed the problem but it made my
machine fail when it booted because of a device checking mechanism in the
boot process.
Is there a way I can force cyrus to use /dev/urandom instead of /dev/random?
Hmm this sounds awfully similar to a problem I described this afternoon, but:
if I understand you correctly, you're not doing an SSL connection, are you? If so, why should /dev/random make a difference? Also, *my* version of Cyrus seems to be already using /dev/urandom (it appeared later in the strace output). I haven't been able to reproduce this, but I expect it to return after some time:
Correct. I am not doing an ssl connection. I'm not sure why /dev/random makes a difference but apparently it does. According to truss, pop3d looks at /dev/random and then goes to sleep. It will return eventually... 5 or 10 minutes later. I find it odd that imapd does not behave the same way but it doesn't.
Jon Rowell
[EMAIL PROTECTED] root]# pop3test -s -m PLAIN -a a0620 -u a0620 pop.uni-koeln.de--
When I do that command, nothing happens for several minutes. I did an strace on the process:
[EMAIL PROTECTED] root]# strace -p 9959
select(0, NULL, NULL, NULL, {0, 680000}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
.... (many more lines like that)
open("/var/lib/imap/tls_sessions.db", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE,
0664) = -1 EEXIST (File exists) brk(0x8097000) =
0x8097000
time([1047377450]) = 1047377450
getpid() = 9959
From that point onwards everything is fine, but it takes literally minutes to get there. Restarting master gets rid of the problem, but that's not really a solution ;-)
Sebastian Hagedorn M.A. - RZKR-R1 (Flachbau), Zi. 18, Robert-Koch-Str. 10
Zentrum für angewandte Informatik - Universitätsweiter Service RRZK
Universität zu Köln / Cologne University - Tel. +49-221-478-5587<mime-attachment>
