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:
*** 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. http://rhn.redhat.com/errata/RHBA-2004-433.html