Check Entropy Levels on Linux

Luke Hebert

June 27, 2017 - 3 minutes read - 509 words

Low entropy on a Linux host can cause noticeable delays during SSL/TLS handshakes, SSH connections, and any operation that depends on the kernel’s cryptographically secure random number generator (CSPRNG). If your servers are stalling on certificate exchanges or you see getrandom() calls blocking, the entropy pool is likely the culprit. Checking it takes one command.

What Is the Entropy Pool?

The Linux kernel maintains a pool of random bits that feeds the CSPRNG. Every time a process requests cryptographic randomness (generating a session key, creating a nonce, seeding a PRNG), the kernel draws from this pool. The pool is replenished by hardware interrupts, disk I/O timing, network packet arrival, and other unpredictable system events.

On a busy server with lots of I/O and network traffic, the pool stays well stocked. On a quiet VM, a container, or a freshly booted system, it can drain quickly and stay low.

Check the Current Entropy Level

The most direct way to see how many bits of entropy are available right now:

cat /proc/sys/kernel/random/entropy_avail

Example output:

The value is expressed in bits. A few reference points:

Above 2000 bits, generally healthy for most workloads.
Below 200 bits, you may start seeing delays in getrandom() or read() calls against /dev/random.
0 bits, the pool is empty; any process waiting on /dev/random will block until new entropy is collected.

You can also watch the pool in real time:

watch -n 1 cat /proc/sys/kernel/random/entropy_avail

Why Low Entropy Matters

SSL/TLS handshakes need random session keys. If the pool is dry, the handshake stalls until entropy is collected.
SSH uses the CSPRNG for key exchange and session encryption.
Databases and application servers that generate tokens, nonces, or IVs will block.
Containers and VMs are especially vulnerable because they generate fewer hardware interrupts than bare-metal hosts.

Raising Entropy When Needed

If the pool consistently sits below a comfortable threshold, consider one of these approaches:

Install haveged, a user-space daemon that feeds the kernel pool using the HAVEGE algorithm. It is the most common fix for VMs and containers.

# Debian/Ubuntu
sudo apt install haveged
sudo systemctl enable --now haveged

# RHEL/CentOS
sudo dnf install haveged
sudo systemctl enable --now haveged

Use rng-tools, which reads from a hardware random number generator (TPM, Intel RDRAND, or an external USB RNG) and feeds the kernel pool.
```
sudo apt install rng-tools
sudo systemctl enable --now rng-tools
```
Increase I/O and network activity, not a practical fix for production, but useful to confirm the diagnosis. A burst of disk writes or network traffic will refill the pool quickly.

Quick Diagnostic Checklist

Run cat /proc/sys/kernel/random/entropy_avail under load and at idle.
Check whether the host is a VM or container (these generate fewer interrupts).
Look for blocked processes: ps aux | grep -i random or strace -e trace=read -p <pid>.
Verify that haveged or rng-tools is installed and running if the pool stays low.

Keeping an eye on entropy is a small habit that saves a lot of head-scratching when a TLS handshake suddenly takes five seconds instead of fifty milliseconds.