stuck lmtpd processes

[Jonathan Marsden]

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

A longer term fix may be to recompile the affected code to use
/dev/urandom for its entropy source, rather than /dev/random?

Hope this helps,

Jonathan
--
Jonathan Marsden       	| Internet: jonathan at xc.org	| Making electronic 
1252 Judson Street  	| Phone: +1 (909) 795-3877	| communications work 
Redlands, CA 92374     	| Fax:   +1 (909) 795-0327	| reliably for Christian 
USA            		| http://www.xc.org/jonathan	| missions worldwide