From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4)
Gecko/20011019 Netscape6/6.2

Description of problem:
When available entropy becomes exhausted for an extended period of
time it fails to recover no matter what actions are taken. The only
action that gets entropy stirred back into the pool is a reboot. 

This behavior occurs in server environments (read no mouse or
keyboard). I've seen it in both rh el as 3 and rh 8. Kernels
2.4.21-9.0.1.ELsmp and 2.4.20-20.8smp. The situation happens on
systems that are primarily web servers and others that are database
servers. 

Both environmens make extensive use of ssl and ssh. All services are
configured to use /dev/urandom so blocking is not a problem but we are
concerned by the reduced cryptographic quality of using a PRNG instead
of real entropy. 

I've gone as far as to implement a script that monitors for the
situation(entropy less then 8192 bits)  and  attempts to stir entropy
by executing disk intensive commands such as find /; man -K  the
process disk ; cat /var/logs/* ... etc.

I've bumped the poolsize to max of 8192. (65536 bits)

The script helps but does not eliminate the problem.

I've googled this and seen references to accounting problems related
to the entropy pool but nothing about the pool not recovering from an
exhausted state. 

I'd very much like to see this addressed in the near term. This seems
to be an area where there is much controversy. So I'd like to
understand RH plans; in order for me  determine if I should be looking
for an alternative/external source for cryptographic quality
randomness. If RH has no plans to address this then I can look at
other sources. But since the OS is advertised to handle this I'd
prefer not to. 

Version-Release number of selected component (if applicable):
2.4.21-9.0.1.ELsmp (rhel as 3) & 2.4.20-20.8smp ( rh 8)

How reproducible:
Always

Steps to Reproduce:
1. setup server without active mouse or keyboard activity
2. start any application that make heavy use of /dev/urandom or
/dev/random, such as ssh; apache with mod ssl; RH cluster suite... etc.

    

Actual Results:  entropy_avail goes to 0 after an unspecified amount
of time; and never recovers 

Expected Results:  entropy_avail increases when I/O or other interrupt
driven events occur.

Additional info: