delayed response from pop3d
Sebastian Hagedorn
Hagedorn at uni-koeln.de
Tue Mar 11 14:40:53 EST 2003
-- Jon Rowell <jrowell at place.net> 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:
> [root at lvr1 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:
>
> [root at lvr1 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : https://lists.andrew.cmu.edu/mailman/private/info-cyrus/attachments/20030311/d18da899/attachment.bin
More information about the Info-cyrus
mailing list