Cyrus lagging accepting IMAP connections

[Scott M. Likens]

1. Not likely, but not impossible... To Quote a source

The /dev/random device hands out "high-quality" random bits, up to the
limit of the "random" information it has been seeded with. The
/dev/urandom device does not have this limitation. It continues to hand
out bits of decreasing quality as long as it is polled.

2. mknod /dev/random c 1 8 (you may need to chmod it to ensure it can be
read of course)

3. You can use aptitude to get the SASL source, then using the Debian
Modified/patched Sources, you can run configure and then install it into
a temporary directory and then create a .deb out of that, however you
will want to freeze that afterwards so you don't download an updated
version that sets you back.

Alternatively, you can report the bug to the debian people, and have
them re-compile it to use /dev/urandom instead of /dev/random and save
you the effort.  However that may take a few days.

If you wish to make your own package, you can read this
http://linuxdevices.com/articles/AT8047723203.html

Additionally Google will be your friend on how to build Debian Packages,
as I haven't done so in quite some time thankfully.

Scott

Rick Kunkel wrote:
> Hm!  I did some additional reading after receiving this, and it seems
> that pursuing the random number generator path is the way to go...
>
> A coupla quick questions (that I think are likely going to be answered
> with "it depends" answers):
>
> 1.  Is nuking /dev/random in the way described going to have adverse
> affects on other elements/services?
>
> 2.  If, andter going this, I want to restore /dev/random to what it
> was beforehand, how would I go about doing that?
>
> 3.  We used aptitude (in all its inflexibility) to install sasl.  Does
> anyone know if there is an easy way to change this compile-time flag,
> but still use aptitude to install SASL?  (Probably off-topic for this
> list, I admit.)
>
> Thanks!
>
> Rick Kunkel
>
> On Tue, 11 Sep 2007, Scott M. Likens wrote:
>
>> Rick,
>>
>> This problem is related to Debian using /dev/random instead of
>> /dev/urandom.
>>
>> Short term solution would be to rm /dev/random
>>
>> mknod /dev/random c 1 9
>>
>> The other solution for you would be to recompile the sources and change
>> the configure to use urandom instead of random... You can search the
>> archives and search for urandom on how to do that.
>>
>> Scott
>>
>> Rick Kunkel wrote:
>>> Hello all,
>>>
>>> I'm new to Cyrus.  Historically, I've used Qpopper, Sendmail, and UW
>>> IMAP.
>>> We recently switched to Cyrus for IMAP.  It came highly recommended...
>>>
>>> We've got this on a darned burly machine, running some very recent
>>> version
>>> of Debian, with a fast CPU, 4GB RAM, and fast SAS drives.  When testing
>>> the thing, before it went into production, everything worked awesomely.
>>> However, having loaded it with 2300 users, it's suddenly acting
>>> erratically.  (Incidentally, of the 2300 users, almost all are POP
>>> users,
>>> which seems to be working fine.  A few hundred -- at most -- are
>>> IMAP, and
>>> they are split between squirrelmail users and a handful that use
>>> standard
>>> MUAs.)
>>>
>>> The server acts as if it's low on resources or something, or has hit
>>> some
>>> kind of connection limit.  It's speedy as heck WHEN it does it
>>> what's it's
>>> supposed to, but that initial connection is sketchy.  For the first 30
>>> seconds after you restart it, it's generally good, but it goes downhill
>>> from there.
>>>
>>> Testing with telnet exhibits this behavior.  Here's a sample session...
>>>
>>> # telnet mail 143
>>> Trying xxx.xxx.xxx.xxx...
>>> Connected to mail.
>>> Escape character is '^]'.
>>>
>>>
>>> And then it just kinda sits.  Sometimes, after 30 seconds or so
>>>
>>> * OK mail Cyrus IMAP4 v2.2.13-Debian-2.2.13-10 server ready
>>>
>>>
>>> We're currently using the following line in cyrus.conf for imapd:
>>>
>>> imap    cmd="imapd" listen="imap" prefork=1
>>>
>>>
>>> We've messed with tons of different settings here, to little avail.
>>>
>>> There don't seem to be any salient log entries.
>>>
>>> Anyone have any ideas?
>>>
>>> Thanks,
>>>
>>> Rick Kunkel
>>> ----
>>> Cyrus Home Page: http://cyrusimap.web.cmu.edu/
>>> Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
>>> List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
> !DSPAM:46e7181084202125116682!
>
>