Bug 119526 - /proc/sys/kernel/random/entropy_avail goes to 0 and does not recover
Summary: /proc/sys/kernel/random/entropy_avail goes to 0 and does not recover
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Mark DeWandel
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-03-31 02:52 UTC by Jim Richard
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-09-02 04:31:12 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2004:433 normal SHIPPED_LIVE Updated kernel packages available for Red Hat Enterprise Linux 3 Update 3 2004-09-02 04:00:00 UTC

Description Jim Richard 2004-03-31 02:52:40 UTC
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

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:

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:

Comment 1 Ernie Petrides 2004-03-31 22:35:40 UTC

*** This bug has been marked as a duplicate of 117218 ***

Comment 2 John Flanagan 2004-09-02 04:31:12 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.