iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
On a Debian or Ubuntu VPS that genuinely stalls while generating keys or performing other random-dependent operations, install the distribution’s haveged package, enable its service, and verify the kernel’s random counters and service logs. Do not install it solely because /dev/random exists: current Linux guidance treats /dev/random as a legacy interface, and a healthy modern VPS may already have enough entropy or a better kernel random-number path.
First, confirm that low entropy is the problem
Entropy warnings are often blamed for any slow cryptographic operation, but adding a daemon without measuring the symptom can hide the real cause. Low entropy is most plausible when key generation, a TLS setup, SSH host-key creation, disk-encryption initialization, or another operation that requests kernel randomness pauses for an unusually long time. Older kernels, older VPS images, and virtual machines with limited hardware capabilities are more likely to show this behavior.
Before changing the system, record the current state and reproduce the workload that is slow. The following files are practical diagnostics identified in Debian documentation:
cat /proc/sys/kernel/random/entropy_avail
cat /proc/sys/kernel/random/poolsizeentropy_avail reports the kernel’s currently available entropy estimate, while poolsize, when exposed by the running kernel, reports the pool-size value. Capture both before and during the stalled operation. A single reading is not a security verdict: the value changes as applications consume randomness, and a high counter does not prove that every source or interface is trustworthy.
Debian package metadata published in 2024 refers to a 1M pool of random bytes in its package context. That figure should not be treated as a promise that every kernel will print the same number in poolsize; use the value reported by the VPS itself.
Know which interface is actually blocking
Some software still opens /dev/random directly. Other software uses /dev/urandom, a language runtime, or the getrandom(2) system call. Identify the application and its configured interface before attempting a fix. If only one old component is affected, upgrading or reconfiguring that component may be safer than adding a permanent entropy daemon.
What haveged does
haveged is a userspace entropy source. Its HAVEGE algorithm derives an unpredictable stream from indirect effects of hardware events on hidden processor state, including caches, branch predictors, and memory-translation tables. In daemon mode, haveged writes entropy to the kernel random device when the kernel reports that available supply has fallen below its low-water mark.
This makes haveged a feeder for the kernel random subsystem, not a replacement kernel, a hardware security module, or a guarantee of certified random numbers. It does not make a weak VPS host trustworthy, and it cannot correct an application that is using the wrong API or blocking for an unrelated reason.
Why virtualization matters
A VPS normally sees a virtual CPU and a host-controlled execution environment. The timing variation used by HAVEGE can still be useful, but its assumptions are not identical to those of a physical server with a dedicated hardware random-number generator. Treat haveged as an additional source and assess whether the host exposes a virtual hardware RNG or another distribution-supported source before deciding which design is appropriate.
Install haveged on Debian or Ubuntu
Use the package supplied by the operating system rather than downloading an unrelated binary. Debian publishes haveged as a userspace entropy daemon, and Ubuntu publishes it in the Universe repository. The exact package version depends on the release; Ubuntu’s Noble package metadata listed version 1.9.14-1ubuntu2 in 2024.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →- Update the package index:
sudo apt update - Install the package:
sudo apt install haveged - If APT says that no installation candidate exists on Ubuntu, check that the Universe repository is enabled for the release and that the package indexes were refreshed. Do not mix repositories from different Ubuntu or Debian releases.
- Confirm that the executable and unit were installed:
haveged -h systemctl cat haveged
Installing the package does not by itself prove that entropy is being supplied. Continue with service activation and verification.
Enable and start the service with systemd
On a systemd-based VPS, enable the service for future boots and start it immediately:
sudo systemctl enable --now havegedInspect the result:
systemctl status haveged --no-pager
journalctl -u haveged --no-pager -bA successful status should show an active service and a recent start time. The journal can reveal a missing permission, an unsupported option, a failed executable, or a unit that exited immediately. Resolve those errors before interpreting entropy counters.
Check the service after a reboot
Enabling a unit creates the boot-time relationship; it does not test the next boot. After a planned reboot, run:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
systemctl is-enabled haveged
systemctl is-active haveged
systemctl status haveged --no-pagerIf the service is enabled but inactive, inspect the boot journal again. A package upgrade, a changed kernel, or a local unit override can alter startup behavior.
Verify that the kernel and workload changed as expected
Take a baseline before starting the workload, then sample while it runs:
cat /proc/sys/kernel/random/entropy_avail
cat /proc/sys/kernel/random/poolsize
watch -n 1 cat /proc/sys/kernel/random/entropy_availCompare the observations with the same operation before installation. You are looking for an operational improvement—such as a previously stalled key-generation step completing—along with a running service and sensible logs. Do not require the counter to remain at a particular number. The kernel consumes and replenishes entropy continuously, so a moving value is normal.
Also verify the application itself. If an SSH key command, certificate tool, or service still blocks, check its logs and system calls rather than assuming that haveged is being used. A process may be waiting on a file lock, a network timeout, a hardware device, or a library-specific initialization step.
Use haveged’s diagnostic and runtime controls carefully
haveged documents verbosity and test controls for administrators. In a maintenance window, the following invocation displays configuration information:
haveged -v 1 -r 1Do not run a second long-lived daemon this way while the systemd service is already active. Stop or isolate the service first if a foreground diagnostic requires exclusive access, then restore the managed unit afterward.
The documented options have distinct purposes:
-eperforms a one-time feed of entropy.-r 0runs the privileged daemon.-wchanges the kernel wakeup threshold at which haveged supplies more data.
Use the package’s installed manual page for the complete option syntax and defaults:
man havegedChanging a wakeup threshold or starting a one-time feed can affect how and when the service interacts with the kernel. Make one change at a time, record the original setting, and verify the workload afterward.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallLeave cache-size tuning at the default unless measurements justify it
Normal haveged operation tunes itself using virtual-filesystem and CPUID information. That automatic behavior is preferable to copying cache-size values from a different VPS model. Virtual CPUs, kernel versions, and host migrations can change the characteristics that those values describe.
Only adjust cache-related settings when a reproducible diagnostic shows that the defaults are unsuitable. Document the change, test it under the same workload that exposed the problem, and keep a rollback command ready. A larger or more aggressive setting is not automatically more secure and can increase CPU use without improving the application’s behavior.
Understand the modern Linux random-number guidance
Current Ubuntu documentation for random(4) calls /dev/random a legacy interface. It recommends /dev/urandom for normal use. For programs that need randomness during early boot, it recommends getrandom(2), which blocks until the kernel random generator has been initialized. Linux 3.17 introduced getrandom(2).
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →This distinction changes the decision on a modern VPS:
- A normal application should generally use the operating system’s
/dev/urandompath or a library that uses it. - An early-boot application should use
getrandom(2)and tolerate its initialization block instead of trying to defeat the block with an arbitrary userspace feed. - Software that explicitly opens
/dev/randommay be following an obsolete assumption. Update or reconfigure it where possible. - haveged can still be useful during early boot, as a supplementary source, for userspace random-data generation, or on older kernels, but it is not required on every current distribution installation.
Mainline Linux and HAVEGE use related CPU-jitter concepts with different implementations. The existence of that overlap is another reason to measure the real workload instead of treating haveged as mandatory on every host.
Compare haveged with other entropy approaches
The right choice depends on the source you trust, when randomness is needed, and what the VPS exposes. Compare the options rather than selecting a daemon by habit.
| Approach | Randomness source | Early-boot behavior | Virtualization and trust considerations | Operational notes |
|---|---|---|---|---|
| haveged | CPU-event effects collected by the HAVEGE algorithm | Can provide a userspace feed when its service starts; exact boot timing depends on the unit and image | Depends on the variability and isolation of the virtual CPU; treat it as an additional source | Distribution packages are available on Debian and Ubuntu; performs userspace work and should be measured on CPU-constrained VPS plans |
| rng-tools or a similar distribution package | Usually a hardware or kernel-exposed random source, depending on the configured utility and device | Depends on whether the source device is present before the service starts | Requires trust in the physical or virtual RNG exposed by the host | Debian identifies rng-tools and haveged as common remedies; inspect the package and device available on the target release |
| Virtual hardware RNG | Host-provided virtual random device | Can be available very early when the VPS platform exposes it to the guest | Moves part of the trust boundary to the hosting platform and its implementation | Availability is provider- and hypervisor-specific; verify the device instead of assuming it exists |
| Modern kernel interfaces | Kernel-managed random pool and its configured sources | getrandom(2) blocks until initialization completes |
Uses the kernel’s supported design rather than a separate daemon | /dev/urandom is preferred for normal use; update applications that insist on legacy /dev/random |
The table does not establish a universal security ranking. A virtual hardware RNG may be preferable when the host documents it and you trust that boundary; haveged may be a practical supplement when no suitable device exists; modern application interfaces may eliminate the original blocking symptom without either daemon.
Free tools Windows power users keep installed
One-click scans. No signup required.
Troubleshoot common failures
APT cannot find haveged
Confirm the distribution release and repository configuration, then run sudo apt update again. On Ubuntu, verify that Universe is enabled. Avoid installing a package built for another release, because an apparently successful installation can leave an incompatible unit or library.
The unit fails immediately
Read both the status output and the boot journal:
systemctl status haveged --no-pager
journalctl -u haveged -b --no-pagerLook for an invalid option, a permission failure, an executable-path problem, or a conflict with a manually started instance. Remove local unit overrides only after recording them, and reinstall the distribution package if its files are incomplete.
Entropy counters do not rise
First verify that the service is active and that the kernel exposes the files you are reading. Then check the journal and repeat the measurement while a known workload consumes randomness. A flat counter can be normal when consumption and replenishment balance each other; the counter alone cannot demonstrate that the source is secure.
The application still blocks
Determine whether it uses /dev/random, /dev/urandom, or getrandom(2). A modern application may intentionally wait for kernel initialization, while an older application may be making an unnecessary direct /dev/random request. Check application logs, library versions, and startup ordering before increasing haveged’s thresholds.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsCPU usage increases
haveged performs userspace computation. On a small VPS, observe CPU time and load after activation. If the workload is healthy without the daemon, disable it and rely on the distribution’s modern random interfaces or a documented virtual RNG. Do not trade predictable service performance for a daemon that has not solved a measured problem.
You are concerned about random-number assurance
haveged’s manual says its runtime tests are modeled on the AIS-31 specification. Procedure A is recommended for startup tests; Procedure B is suited to daemon operation because it includes an entropy estimate. The same manual states that formal certification is not the goal and that no test is perfect. Treat these tests as operational checks, not proof that the VPS has a certified hardware random-number generator.
Run the built-in tests as operational checks
Use the installed manual and package documentation to select the test mode appropriate to the lifecycle:
- Use Procedure A for a startup-oriented check.
- Use Procedure B for daemon operation when an entropy estimate is useful.
- Record the version, kernel, VPS image, and test conditions with the result.
A passing test tells you that the selected procedure did not detect its modeled failures under those conditions. It does not certify the host, prove independence from other entropy sources, or guarantee future behavior after migration to another physical machine.
Disable or remove haveged when measurement no longer justifies it
If you upgrade an old image, change the application to getrandom(2) or /dev/urandom, or obtain a documented virtual RNG, retest before keeping an extra daemon permanently.
- Stop and disable the service:
sudo systemctl disable --now haveged - Reproduce the original workload and inspect the same counters and logs.
- If the package is no longer needed, remove it through APT:
sudo apt remove haveged - Keep the configuration and test records until you have confirmed that dependent services start correctly after a reboot.
Disabling the daemon does not disable the kernel random subsystem. It only removes haveged’s userspace feed, so applications continue to use the kernel interfaces available on the system.
A practical decision checklist
- Can you reproduce a real delay in key generation or another randomness-dependent operation?
- Which interface does the affected program use:
/dev/random,/dev/urandom, orgetrandom(2)? - Is the VPS running an older kernel or image with limited entropy sources?
- Does the platform expose a virtual hardware RNG that you are prepared to trust?
- Have you recorded
entropy_avail,poolsizewhen available, service status, and journal output? - After installation, did the original workload improve, rather than only the counter changing?
- Have you evaluated CPU cost and confirmed that no second daemon is running?
- Are you treating AIS-31-derived tests as checks rather than formal certification?
If the answer to the first question is no, do not add haveged preemptively. If the answer is yes and the application is legacy software that cannot be updated, the Debian or Ubuntu package, a managed systemd service, and measured verification provide a controlled way to test whether haveged addresses the problem.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
