Free tools Windows power users keep installed
One-click scans. No signup required.
Install haveged only after confirming that your VPS has a genuine random-number shortage. On Debian or Ubuntu, the supported path is to install the distribution package, enable the service, then verify its logs and the kernel’s entropy counters while reproducing the workload that was slow or blocked. On a current Linux system, however, applications should normally use /dev/urandom or getrandom(2); a permanently running haveged daemon is not automatically necessary.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
What “low entropy” means on a VPS
Linux needs unpredictable data for tasks such as generating SSH keys, TLS keys, session secrets and other cryptographic material. A virtual machine may have fewer observable hardware events than a physical server, particularly during early boot or on an older kernel. When the kernel’s random-number generator has not been initialized, or when an older interface waits for additional input, key generation can appear to freeze.
As an Amazon Associate I earn from qualifying purchases.
Do not diagnose the problem from a single low-looking number. First identify the operation that is slow: a key-generation command, a daemon waiting for random data, or a boot-time service. Record the delay and inspect the kernel counters before changing the system. Debian documents /proc/sys/kernel/random/entropy_avail and, where present, /proc/sys/kernel/random/poolsize as practical diagnostics. They are useful indicators, not proof that the resulting bytes are secure.
Check the counters
cat /proc/sys/kernel/random/entropy_avail
cat /proc/sys/kernel/random/poolsizeRun the commands once during an idle period and again while reproducing the suspected workload. Save the values and timestamps. A counter that changes after installing haveged does not by itself establish that an application is using a better or more trustworthy random source.
Check which random interface the application uses
Modern software commonly obtains random data through the kernel’s getrandom(2) system call or through /dev/urandom. Older software may open /dev/random directly. The distinction matters: Ubuntu’s current random(4) documentation describes /dev/random as a legacy interface, recommends /dev/urandom for normal use, and recommends getrandom(2) for early-boot applications because it waits until the kernel generator is initialized.
Linux introduced getrandom(2) in kernel 3.17. If the program can be configured or upgraded to use that interface, fixing the application is often preferable to adding a daemon solely to satisfy an old /dev/random assumption.
What haveged does
haveged is a userspace entropy source. Its HAVEGE (HArdware Volatile Entropy Gathering and Expansion) algorithm derives an unpredictable stream from indirect effects of hardware events on processor state, including caches, branch predictors and memory-translation tables. In daemon mode, it feeds the kernel random device when the kernel reports that available supply is below its low-water mark.
This is supplementary input, not a replacement for every other source of randomness. Its behavior depends on the processor, virtual-machine implementation and kernel. The project describes it as useful for early boot, as an additional source, for userspace random-data generation and on older kernels. It also notes that mainline Linux and HAVEGED use related CPU-jitter concepts implemented differently.
Normal operation is self-tuning: haveged uses virtual-filesystem and CPUID information to choose cache-related settings. Leave those settings at their defaults unless measurements show a specific reason to change them.
What the low-water mark means
haveged does not need to write continuously just because the service is enabled. Its documented daemon behavior is to feed the kernel when the reported supply falls below the kernel’s low-water threshold. That makes service status and the entropy counter separate questions: a healthy daemon can be idle when no feed is needed, while a changed counter does not prove that your application consumed bytes from the feed.
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 reinstallThe daemon’s stream is generated inside the guest. It is therefore different from a virtual hardware RNG, where the hypervisor presents a device backed by the host’s source. On a busy VPS, the CPU time used by haveged is an operating cost; on a platform with a reliable virtual RNG, the guest may obtain random data with little additional guest CPU work. Compare those trade-offs instead of assuming that one mechanism is universally stronger.
Before installation: a safe decision checklist
- Confirm a reproducible delay or block in a real cryptographic workload.
- Identify whether the software is using
/dev/random,/dev/urandomorgetrandom(2). - Check the kernel version and whether the VPS exposes a virtual or hardware random device.
- Check available CPU headroom; haveged consumes processor time while it gathers samples.
- Plan a maintenance window if you will run diagnostic modes or restart a production service.
If the only symptom is a low counter while applications work normally through /dev/urandom or getrandom(2), installing haveged may add complexity without solving a user-visible problem.
Capture a baseline
Write down the distribution release, kernel version, vCPU allocation, whether a virtual RNG device is visible, and the exact command or service that stalls. Take several entropy readings rather than one snapshot. Note whether the delay happens only during the first boot, only immediately after a reboot, or under sustained key-generation load. This baseline lets you distinguish an initialization delay from a continuing shortage and gives you a fair comparison after the service starts.
Also record CPU use while the workload runs. haveged is a userspace process, so a successful change in latency can still be a poor trade if it consumes a material share of a small VPS. The relevant cost is not a package purchase price: it is guest CPU time, another service to monitor, and any dependency on a legacy application interface.
Install haveged on Debian or Ubuntu
1. Refresh package metadata
sudo apt updateUbuntu publishes haveged in the Universe repository. If the package is not found on an Ubuntu installation, verify that Universe is enabled for the release before retrying the update. Debian publishes haveged as a userspace entropy daemon through its normal package repositories.
2. Install the distribution package
sudo apt install havegedUsing the distribution package keeps the daemon, service definition and documentation aligned with the operating system. Ubuntu’s Noble package metadata listed version 1.9.14-1ubuntu2 in 2024; the exact version you receive depends on your release and repository updates. Debian package metadata from 2024 also described a 1M pool of random bytes; that figure is package metadata, not a promise of cryptographic quality or a throughput benchmark.
Do not copy a binary or service unit from another release merely because its version number looks newer. Package maintainer choices, init integration and option defaults can differ. The repository package is also the easiest version to remove or update through the normal security and maintenance workflow.
3. Enable and start the service on systemd hosts
sudo systemctl enable --now haveged
systemctl status havegedenable --now starts the service immediately and arranges for it to start at subsequent boots. Read the status output rather than assuming that a successful package installation means the daemon is running.
4. Inspect the service log
sudo journalctl -u haveged -b
sudo systemctl is-enabled haveged
sudo systemctl is-active havegedLook for a failed start, permission error, unsupported CPU information or a service that exited immediately. On a distribution release without systemd, use the init script supplied by that release’s package and consult its service documentation; do not copy a systemd unit from another distribution.
Verify that haveged changed the behavior
Compare counters, not just service status
cat /proc/sys/kernel/random/entropy_avail
# reproduce the workload here
cat /proc/sys/kernel/random/entropy_availCompare the readings with the values recorded before installation and inspect the timestamped service log. A running service confirms that haveged is present; it does not prove that a particular application is waiting on the interface haveged feeds.
Re-test the original operation
Repeat the exact key-generation or startup operation that exposed the problem. Keep the test controlled: use a temporary output path, avoid replacing production keys and record elapsed time. If the operation still blocks, inspect the application’s random-device configuration and its system calls instead of increasing haveged’s settings blindly.
Check boot timing separately
If the failure occurs only during boot, compare the service ordering with the application that waits for randomness. A daemon started after the application cannot solve that application’s earliest initialization attempt. The modern alternative is often to make the application call getrandom(2), which deliberately waits until the kernel generator is initialized. If the workload is an older service that cannot be changed, document the ordering dependency and test a full reboot rather than only restarting haveged after the system is already running.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Use haveged’s diagnostic controls only when needed
The daemon documents verbosity and test controls. In a maintenance window, haveged -v 1 -r 1 can display configuration information. The documented options include:
-e: perform a one-time feed rather than staying resident.-r 0: run the privileged daemon.-w: change the kernel wake-up threshold.
Option behavior can vary with the packaged version, so read the installed manual with man haveged before using a non-default command. Do not launch a second daemon on a production host while the service is already running.
A one-time feed is useful for a controlled diagnostic, not as a replacement for correctly managing the service. If you change a wake-up threshold, record the old value, the reason for the change and the observed result. Revert an experiment that increases CPU use without improving the original workload.
Understanding haveged’s runtime tests
The haveged manual describes runtime tests modeled on the AIS-31 specification. Procedure A is intended for startup tests. Procedure B is suited to daemon operation because it includes an entropy estimate. These checks can reveal a malfunctioning configuration or an unexpected runtime condition, but the manual explicitly says that formal certification is not the goal and that no test is perfect.
Therefore, a passing haveged test is an operational check, not certification that your VPS contains a certified hardware random-number generator. Treat the result as one piece of evidence alongside kernel initialization, service logs, the virtual hardware configuration and the application’s actual random interface.
Why haveged may not be the right fix on a modern VPS
Modern interfaces usually avoid the old blocking pattern
Ubuntu’s current random-device guidance says that /dev/urandom is preferred and sufficient for normal use. For early boot, getrandom(2) blocks until the kernel random generator is initialized, which gives an application a clear readiness guarantee without requiring it to poll or depend on the legacy /dev/random device.
If your application is current and the VPS boots normally, a continuously running haveged process may provide little practical benefit. First update or reconfigure software that incorrectly treats /dev/random as the only safe interface. Keep haveged when measurements show a real early-boot or legacy-kernel problem, when it is required by an older workload, or when it is deliberately used as a supplementary source.
Virtualization changes the trust assumptions
A virtual machine does not necessarily expose the same processor timing behavior or hardware RNG access as its host. A virtual hardware RNG can be excellent when the host provider supplies and maintains it, but it also introduces a dependency on that provider and on the hypervisor’s implementation. haveged instead uses processor-state effects inside the guest and consumes CPU while doing so. Neither choice removes the need to understand the kernel and application interfaces.
Do not confuse a larger pool with better randomness
The kernel’s counters describe accounting, not a certificate of unpredictability. Likewise, the Debian package metadata reference to a 1M pool of random bytes describes package information, not a guaranteed quality level or a measured generation rate. Evaluate whether the original operation completes correctly, whether the source fits your trust model and whether the ongoing CPU and maintenance costs are acceptable.
Alternatives and how to choose
| Option | Randomness source | Early-boot availability | Main assumptions | Operational cost |
|---|---|---|---|---|
| haveged | CPU timing and indirect processor-state effects gathered by HAVEGE | Can help when started early, subject to service ordering and kernel initialization | Guest CPU behavior provides a useful supplementary source | Userspace daemon and CPU overhead; distribution package support varies by release |
| rng-tools | Depends on the configured hardware or kernel RNG source | Depends on whether that source is available before services start | A usable RNG device or source is exposed to the guest | Package and service configuration; source-specific behavior |
| Virtual hardware RNG | Host-provided device, often exposed through the hypervisor | Potentially available very early, if the VPS provider exposes it | Trust in the host and correct virtual-device configuration | Usually low guest CPU cost; availability is provider- and platform-dependent |
Application using getrandom(2) or /dev/urandom |
Linux kernel random generator and its configured inputs | getrandom(2) waits for initialization; /dev/urandom is intended for normal use |
Application is modern enough to use the supported interface | No additional daemon, but old early-boot code may need changes |
Choose by measuring the actual workload. Consider source of randomness, early-boot timing, trust and virtualization assumptions, package support, CPU overhead and the interface the application uses. A hardware RNG or rng-tools configuration is not automatically superior if the VPS does not expose a reliable device; haveged is not automatically superior merely because it raises a counter.
Questions to ask a VPS provider
When comparing hosts, ask whether a virtual hardware RNG is exposed to guests, whether it is available during early boot, and which hypervisor mechanism supplies it. Treat a provider’s answer as an infrastructure dependency to document, not as a substitute for testing inside your own image. A hosting comparison focused on documented entropy support and virtual-RNG availability is more useful than a generic CPU or storage benchmark for this particular problem.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesTroubleshooting common failures
“Unable to locate package haveged”
- Run
sudo apt updateand read its repository errors. - On Ubuntu, confirm that the Universe repository is enabled for the installed release.
- Check the release’s package availability and architecture instead of installing an unrelated binary.
The service fails to start
- Read
sudo journalctl -u haveged -bfor the first error, not only the final “failed” line. - Check whether another entropy service or manually started haveged process is already running.
- Verify that the VPS kernel exposes the interfaces the packaged service expects.
- Restore the distribution unit and defaults before experimenting with thresholds or cache-size parameters.
The counter does not rise
Do not keep increasing thresholds solely to obtain a larger number. The counter reflects kernel accounting and can be affected by workload and kernel version. Confirm that the service is active, inspect its log, and test the original application. If the program uses getrandom(2) or /dev/urandom, a counter change may not be the relevant success criterion.
The application still blocks
- Confirm whether it is waiting during early boot, when any correctly used random interface may wait for initialization.
- Check for a hard-coded
/dev/randompath or an outdated library. - Test after the kernel has initialized its random generator and compare with a modern build of the application.
- Do not substitute a pseudo-random file or copy random bytes from another machine; that bypasses the security property you are trying to preserve.
CPU usage becomes noticeable
Measure the daemon’s CPU consumption against the VPS’s available vCPUs and workload. haveged is a userspace process, so the trade-off is different from a host-provided virtual RNG. If the original problem is gone and the application uses modern interfaces, disabling the daemon may be the more appropriate optimization.
Service status is active but nothing improves
This usually means the test is measuring the wrong layer. Confirm that the stalled process actually opens /dev/random or otherwise depends on the kernel supply that haveged feeds. A service can be active while an application waits for a separate early-boot condition, a library timeout or an unavailable virtual device. Return to the baseline, compare elapsed time and inspect logs before changing daemon parameters.
Removing haveged after a test
If measurements show no benefit, stop and disable the service, then remove the package only if nothing depends on it:
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →sudo systemctl disable --now haveged
sudo apt remove havegedRecheck the original workload after removal. If a legacy service regresses, document that dependency and decide whether updating the service, exposing a virtual RNG or retaining haveged is the better long-term solution. Do not remove another package merely because it also mentions entropy; inspect its dependency list first.
Operational checklist
- Reproduce and time the real cryptographic operation.
- Record
entropy_avail,poolsizewhere available, kernel version and the application’s random interface. - Install the Debian or Ubuntu package with
apt. - Enable and start haveged using the distribution’s service manager.
- Review status and boot logs.
- Repeat the workload and compare behavior, not just the counter.
- Leave tuning at defaults unless diagnostics justify a documented change.
- Prefer application fixes using
getrandom(2)or/dev/urandomon modern systems. - Remove the daemon when it provides no measurable value and adds unwanted CPU or maintenance cost.
Frequently Asked Questions
How do I add entropy to a VPS using haveged?
Confirm a real blocking or slow cryptographic workload, install haveged with sudo apt update && sudo apt install haveged, enable it with sudo systemctl enable --now haveged, then review status, logs and kernel counters while repeating the workload.
Why is /dev/random blocking on my VPS?
The kernel may not yet have initialized its random generator, or older software may be waiting on the legacy interface. Check when the block occurs, identify the application’s interface, and prefer getrandom(2) for early boot or /dev/urandom for normal use.
Do modern Ubuntu and Debian servers still need haveged?
Not automatically. Current Linux guidance generally favors /dev/urandom and getrandom(2). Keep haveged when measurements show an early-boot, older-kernel or legacy-application problem, or when you intentionally use it as a supplementary source.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Does a higher entropy_avail value prove that the VPS is secure?
No. The counter is an operational diagnostic, not proof of cryptographic quality. Judge the actual workload, kernel initialization, source trust and application interface together.
Is haveged better than a virtual hardware RNG?
Neither is universally better. haveged derives samples from guest processor-state effects and uses guest CPU time; a virtual RNG can have low guest overhead but depends on the provider and hypervisor. Compare availability, trust assumptions, package support and measured behavior.
What does haveged’s 1M random-byte pool mean?
The 1M figure appears in Debian package metadata. It is not a throughput benchmark, a certification or a guarantee that every generated byte has a particular quality level.
Can I run haveged’s tests as a certification check?
No. Its runtime tests are modeled on AIS-31. Procedure A is intended for startup and Procedure B for daemon operation with an entropy estimate, but the manual states that formal certification is not the goal and no test is perfect.
How can I remove haveged safely?
Run sudo systemctl disable --now haveged, remove it with sudo apt remove haveged if no package depends on it, and repeat the original workload. If a legacy service regresses, choose between updating that service, exposing a virtual RNG and retaining haveged.
The Bottom Line
Use haveged as a measured, supplementary fix—not as a default VPS requirement. Establish that a real workload is blocked, install the Debian or Ubuntu package, verify the service and logs, and retest the workload rather than chasing a larger counter. On modern Linux, fixing software to use /dev/urandom or getrandom(2) is often the cleaner long-term answer; retain haveged only when its benefit and operating cost are clear.
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.
