From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4)
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
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
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)
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.
*** This bug has been marked as a duplicate of 117218 ***
An errata has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.