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: [EMAIL PROTECTED] | 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
