Entropy on Linux: urandom and haveged for Fast PHP Sessions

1. Why entropy shortage silently delays requests

Anyone investigating performance problems on Magento servers usually checks CPU, memory, disk I/O, and network first. The quality of the random number generator is rarely among the first suspects, even though in certain environments it can be just as real a cause of latency as any of these more classic metrics.

Every cryptographically secure random number an application requests on Linux, whether for a session ID, a CSRF token, or the key exchange in a TLS handshake, ultimately comes from the kernel's entropy pool. This pool is continuously fed from unpredictable events: interrupt timing, disk access, network packets, and, on physical hardware, mouse and keyboard movements. If the collected entropy is insufficient, a random number call can end up blocking until enough new entropy has been gathered.

For a Magento web server this means: PHP internally calls a kernel function that supplies random data on every session_start() and every use of random_bytes(). On a well utilized bare metal server with diverse interrupt sources, entropy shortage is rarely a problem, because the pool is constantly refilled by natural system activity. On freshly started virtual machines or in minimal container images, the situation looks completely different.

The insidious part of entropy shortage is its invisibility in classic performance metrics: CPU usage stays low, the network connection is not saturated, and yet a request seemingly hangs for no reason for a few hundred milliseconds to a few seconds. Only a targeted look at the entropy pool level uncovers the actual cause in such cases.

2. /dev/random, /dev/urandom, and getrandom() compared

This distinction regularly causes confusion in practice, especially since older tuning guides sometimes contain outdated recommendations about /dev/random that no longer apply on modern kernel versions.

Historically, Linux offered two random number generators as device files: /dev/random, which blocks once the kernel's estimated entropy supply is exhausted, and /dev/urandom, which practically never blocks after the initial kernel boot phase, because it uses a cryptographically secure pseudo random number generator (CSPRNG) that, once seeded with enough entropy, keeps producing strong output. For nearly all use cases, including cryptographic keys, /dev/urandom has been the correct choice for years, since modern CSPRNGs deliver cryptographically strong output even with limited initial entropy.

Since Linux kernel version 3.17, the getrandom() system call has also existed, which modern PHP versions use internally for random_bytes() and random_int(). getrandom() only blocks once, right after system startup, until the kernel CSPRNG has been initially seeded with enough entropy, and afterward supplies random data without further blocking. This one time initialization phase is exactly the critical moment where a freshly started server or container can unexpectedly hang if no sufficiently fast entropy source is available.

# Check the current entropy pool size the kernel considers available
cat /proc/sys/kernel/random/entropy_avail

# On modern kernels this typically reports a high value (thousands)
# once the CSPRNG has been fully seeded after boot

3. How the kernel collects entropy

A basic understanding of these collection mechanisms explains why certain server classes are structurally more prone to entropy shortage than others, regardless of the specific Linux distribution or kernel version.

The kernel gathers entropy from several independent sources and mixes it into an internal pool. On physical hardware, interrupt timing from disks, network cards, and, on desktop systems, input devices provide a continuous stream of unpredictable events. Modern CPUs also often come with a hardware random number source, such as the RDRAND instruction on x86 processors, which the kernel can use as an additional, very fast entropy source, provided it is classified as trustworthy.

This collection happens fully automatically without any administrator involvement, as long as suitable sources exist at all, which makes the next section the central question.

On servers without physical input devices and without spinning disks, as is the case with most cloud instances and dedicated servers with pure SSD/NVMe storage, two traditionally important entropy sources disappear completely. The kernel then relies more heavily on network interrupt timing and, if available, a hardware RNG instruction to fill its pool, which in certain configurations can lead to a noticeably slower initial fill.

This gap is the actual starting point for the tools described in the following sections, which are meant to compensate for exactly these missing sources.

4. Why VMs and containers are especially affected

Virtual machines are especially prone to entropy problems because the hypervisor either does not pass through many of the physical hardware interrupts a bare metal system draws entropy from, or virtualizes them in a form that provides less unpredictable timing. A freshly booted cloud server can therefore have noticeably slower access to cryptographically secure random data in the first few seconds after startup than a comparable bare metal system, even if both use the same Linux kernel.

This vulnerability affects not only the initial boot process but can reappear on every restart, every autoscaling event, and every deployment of a new image, as long as no additional entropy source is configured.

Autoscaling groups in the cloud are particularly affected by this, since by definition they are designed for fast, repeated spin up of new instances, each carrying the same potential entropy bottleneck during its startup phase.

Containers tend to worsen this problem further, because several containers on the same host typically share the same kernel entropy pool and do not perform their own, isolated entropy collection. If a large number of PHP-FPM containers start simultaneously, for example after a deployment or an automatic scaling event, and each container performs cryptographic operations during startup, this can briefly cause a noticeable delay until the shared host pool supplies enough entropy.

5. Impact on PHP: sessions, random_bytes, and TLS

This chain of random number requests is re-created on every single checkout, which is why it is not a one off edge case but a recurring load on the entropy pool with every new customer request.

PHP uses random data at several critical points: session_start() generates a new session ID with cryptographically secure randomness, random_bytes() and random_int() are frequently used for CSRF tokens, password reset links, and API keys in Magento extensions, and every TLS handshake a PHP process performs as a client, for example when calling an external payment or shipping API, also needs random data for the key exchange.

In security critical contexts such as payment processing and authentication, a robust random source is non negotiable in any case. The measures described here therefore address exclusively the performance side of this topic, without compromising the cryptographic strength of the generated random data.

During a Magento checkout process with payment provider integration, these calls add up: session creation on the first page view, a CSRF token for the order form, and an outgoing TLS handshake to the payment provider can all request random data in quick succession. On a system with a sufficiently filled entropy pool this is entirely unproblematic; on a freshly started container without an additional entropy source, these calls can instead add up to a noticeable, if usually short, delay.

Recurring background processes such as sending confirmation emails over an encrypted SMTP relay, or synchronizing with an external inventory system, can also trigger additional TLS handshakes that draw on the same entropy pool as the actual customer interaction.

6. Setting up haveged and rng-tools as an entropy source

Both approaches deserve a closer look before deciding which one, or which combination, fits a given infrastructure best.

Both tools have been available in the standard repositories of all common Linux distributions for years and generally come with sensible default settings, so manual fine tuning is only needed in exceptional cases.

haveged is a daemon that generates additional entropy based on CPU timing variations and feeds it into the kernel pool, without relying on physical hardware interrupts. For servers without a mouse, keyboard, or spinning disks, haveged is one of the simplest and most reliable solutions for keeping the entropy pool consistently well filled even without these classic sources. Installation is remarkably simple on most distributions and requires no further configuration for standard operation.

For most Magento hosting environments without special compliance requirements on the randomness source, haveged alone is entirely sufficient and, in practice, by far the most commonly chosen solution.

Alternatively or in addition, rng-tools can be used with the rngd daemon, which feeds hardware random number sources such as RDRAND or a Trusted Platform Module (TPM) directly into the kernel pool. On servers with a corresponding hardware RNG source, this approach is often the preferred choice because it uses genuine hardware randomness instead of deriving it from CPU timing variations.

# Install and enable haveged as an additional entropy source
sudo apt-get install haveged
sudo systemctl enable --now haveged

# Verify it is running and check the resulting entropy pool level
systemctl status haveged
cat /proc/sys/kernel/random/entropy_avail

7. Using virtio-rng for virtual machines

This option matters most for KVM based deployments, where the guest otherwise depends entirely on its own, often limited entropy collection.

For KVM based virtual machines, virtio-rng provides a direct, paravirtualized channel to the host system's entropy source. Instead of leaving the guest VM dependent on its own, often insufficient entropy collection, the hypervisor forwards entropy from the host, which usually has enough sources of its own, directly to the guest. This is already enabled by default on many cloud platforms, but should be explicitly configured in the VM definition for self managed KVM environments.

Anyone running their own KVM hosts should add this configuration to the standard VM template, so that every newly created virtual machine has a reliable entropy connection from the start, instead of having to retrofit it per instance afterward.

A similar concept exists for Xen based virtualization, and large cloud providers also offer their own virtualized hardware RNG interfaces. Before putting a new VM image into service, it is therefore always worth a quick check whether a virtualized RNG source is already active, before additionally installing haveged, since both approaches do not exclude each other but are often redundant when virtio-rng is already present.

An important distinction is the backend type in the virtio-rng configuration: /dev/random as backend can theoretically block on the host, while /dev/urandom as backend, as shown in the example below, practically never blocks and is therefore the more pragmatic choice for most setups.

<!-- libvirt domain XML: add a virtio-rng device backed by /dev/urandom -->
<devices>
  <rng model="virtio">
    <backend model="random">/dev/urandom</backend>
  </rng>
</devices>

8. Monitoring entropy pool levels

A sensible alert threshold sits well below the values a healthy system shows in normal operation, since short term fluctuations are normal and not every small dip requires immediate action.

Continuous monitoring of this metric belongs in the same category as watching load average or free memory: unremarkable in normal operation, but decisive for quick diagnosis when a problem actually occurs.

The simplest diagnostic step is a regular look at /proc/sys/kernel/random/entropy_avail, which shows the kernel's estimated available entropy in bits. A persistently low value, especially shortly after a system or container start, indicates a potential problem and justifies setting up an additional entropy source such as haveged or virtio-rng.

Ideally this value is integrated into an existing monitoring system such as Prometheus, Zabbix, or Nagios, rather than only checked manually after a problem has already occurred.

For deeper diagnosis, blocking getrandom() calls can be made visible with strace on an affected PHP-FPM process. If a getrandom() call appears in the trace output with a conspicuously long duration, that is a strong indication of actual blocking due to insufficient entropy, rather than some other, unrelated cause of the observed delay.

# Trace a specific PHP-FPM worker for blocking getrandom() calls
sudo strace -f -e trace=getrandom -T -p "$(pgrep -f 'php-fpm: pool' | head -1)"

# The -T flag shows the time spent in each syscall;
# an unusually long getrandom() call indicates entropy starvation

9. Solutions side by side

Which approach fits a given case depends less on personal preference than on the concrete infrastructure: bare metal servers, KVM VMs, and container hosts each benefit from different combinations of these tools.

The following table compares common approaches for fixing entropy shortage across different server environments.

The table shows: for virtualized and containerized Magento infrastructures, an explicit entropy strategy is not an optional detail but a sensible baseline safeguard against sporadic, hard to diagnose latency spikes.

For new server templates, it is therefore advisable to include one of the mentioned solutions in the standard provisioning from the start, rather than retrofitting it reactively after a concrete incident. Once established, monitoring of the entropy level also makes this decision verifiable at any time, without requiring another manual diagnosis.

For teams running several Magento instances across different infrastructure, from bare metal through KVM to container platforms, a unified policy is worthwhile: which entropy solution is the standard for which infrastructure type, and how is its correct functioning automatically verified during server provisioning, rather than relying on a one time manual check.

10. Summary

Entropy shortage on Linux is one of the hardest causes of sporadic latency spikes to diagnose, because it does not show up in any of the usual performance metrics. /dev/urandom and the more modern getrandom() system call are the right choice for practically all use cases, but can block right after system startup if the kernel CSPRNG has not yet been sufficiently seeded, an effect that particularly affects virtual machines and containers.

haveged provides a simple, hardware independent solution for servers without physical entropy sources, while rng-tools uses genuine hardware random sources such as RDRAND, and virtio-rng in KVM environments enables direct access to host entropy. A regular look at entropy_avail and targeted strace diagnosis of blocking getrandom() calls help identify the problem before it shows up as hard to explain checkout delays.

11. FAQ: Entropy on Linux for PHP Sessions