On Wed, 24 Sep 2003, Jonathan Marsden wrote:
> On 24 Sep 2003, Andrew Morgan writes:
>
> > I've just ran into this problem again. This time I have the gdb
> > backtrace of both the lmtpd process trying to get the lock and the
> > imap process holding the lock. There is nothing new in the lmtpd
> > backtrace. Here is the imapd backtrace:
>
> > 0x402ae3c4 in read () from /lib/libc.so.6
> > (gdb) bt
> > #0 0x402ae3c4 in read () from /lib/libc.so.6
> > #1 0x40111fc4 in TXT_DB_version () from /usr/lib/libcrypto.so.0.9.6
> > #2 0x41754277 in ?? ()
> > Cannot access memory at address 0x62416b47
>
> > So I'm a little stuck here. I don't know enough about gdb to find
> > out what it is actually trying to read from, although the network
> > seems like a reasonable guess.
>
> I'm guessing here, but is this at all related to the "insufficient
> randomness" thing where reading from /dev/random hangs until more
> entropy gens generated? A read from code in libcrypto that hangs
> things ... it all sounds strangely familiar!
>
> If my guess is somewhat close to correct, then a temporary workaround
> (which worked on Red Hat 7.3 for me) may be to do
>
> cd /dev
> mv random random.orig
> ln -s urandom random
Ugh, no thanks on this workaround.
> A longer term fix may be to recompile the affected code to use
> /dev/urandom for its entropy source, rather than /dev/random?
I've already compiled cyrus-sasl to use /dev/urandom. I'm not sure where
else I can change that, assuming this is the problem.
Andy
