stuck lmtpd processes

[Andrew Morgan]

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