Viktor's picture

I have intalled the Wordpress LXC on the latest Proxmox but after running for some time normally, the CPU usage spikes to 100% due to `jitterentropy-rngd`.

What could be causing this? Can I disable the jitterentropy-rngd service?

Many thanks

Jeremy Davis's picture

Firstly it's worth noting that jitterentropy-rngd service generates entropy (i.e. 'randomness'). That is particularly important when running on a VM, although I'm not sure about LXC?! When you are running on hardware it's not such an issue as a lot of entropy is generated by the hardware and most modern hardware actually have specific RNG (random number generator) hardware. As an LXC container actually shares resources with the host, perhaps it's not even required?

If it is actually doing anything of value, it's most likely to be important on firstboot and/or when generating SSH keys and other similar tasks (that require "randomness"). There are also some applications that require some "randomness" at boot time. After boot (and firstboot in particular and/or when you want to generate keys) I'm sure that you can get away without having it running - even on a VM.

So I'm fairly sure that stopping it will have little to no bad effect. Do that like this:

systemctl stop jitterentropy-rngd

If you want to disable it, you can do it like this:

systemctl disable jitterentropy-rngd

I would recommend testing a reboot after you disable it though and see if it affects the boot time.

FWIW the reasons why we included it in v16.x were:

  • super slow boot times on VMs, especially slow on low resource VMs (without it)
  • error/warning messages in the logs at boot time re low entropy (without it)
  • no ill effects discovered during testing (with it)

I'd be really interested to hear a bit more about your setup and whether you've done anything special with this LXC containers config and what (virtual) resources you have assigned to it.

I'd also be interested to hear your experiences after stopping and/or disabling the service (e.g. does it seem to make any difference, other than reducing CPU usage? does it change boot time? etc?)

Also FWIW, I do have some LXC containers running myself and haven't noticed any issues. However, I have an old version of Proxmox so perhaps it's something that only occurs with newer machines? (I need to upgrade, but I just haven't had enough spare time to deal with potential issues).

One other possibility is that perhaps you just need to add more CPU resources (if it's got low CPU resources allocated)?

Viktor's picture

Thanks for the exhaustive and quick reply Jeremy!

The issue occurs on every reboot of a stock Wordpress 16.1-1 container. I tried with increasing the cores to 4 and it still hangs forever at 100% CPU usage.

Now after the initial setup I disabled the service and all seems to be working fine. Is an update to the container planned since it is using PHP 7.3 which is not supported by many plugins and enters EOL this year?

Jeremy Davis's picture

Thanks for your response - and your initial report!

I've just done a bit of searching and discovered that you are not the first to notice this, but unfortunately, no one has bothered reporting it directly to us before now...! :(

I haven't personally experienced it, but following your report I've had a closer look. I can confirm that even though it doesn't negatively affect my containers, it also doesn't seem to give any benefit! So I've opened a bug report to remove (or at least disable it) in future LXC builds.

To answer your PHP question:

As background, whenever possible, we install everything (including PHP) from the official Debian repositories. Debian has a great reputation for providing timely, relevant and well tested backported security patches (i.e. updates) for software in the official repositories. We enable these security updates to auto install nightly.

So whilst you are correct to note that upstream PHP 7.3 support will be EOL later this year, the Debian security team (until July, 2022 and after that, the LTS team) will backport security patches to PHP 7.3 for Debian 10/Buster (the basis of TurnKey v16.x) until June, 2024 (and possibly longer via ELTS).

Obviously that doesn't address the second component of your question ("PHP 7.3 which is not supported by many plugins"). I'm not super familiar with the whole WordPress ecosystem, but I would expect the most popular plugins to support the same PHP version as WordPress itself? (currently PHP5.6). Having said that, I guess that point is somewhat irrelevant if a particular plugin you wish to use doesn't support it.

The next stable release of Debian (11/Bullseye) will be released really soon (likely to drop within a few weeks) and that will include PHP7.4. It's highly unlikely that we'll release updated appliances in that timeframe, but hopefully won't be too far away.

In the meantime, if you want a newer PHP version then there is Ondřej Surý's repo. He provides current versions of PHP for various versions of Debian. Note though, that he only provides versions supported by upstream PHP.

WoRie's picture

To chime in here: I've just used a turnkey core template under Proxmox and encountered the same issue. The jitterentropy process uses 100% of CPU time until killed and disabled. So it's not only the Wordpress build but at least the core build as well. I came across this thread while searching for a solution to the high cpu usage.

Jeremy Davis's picture

Thanks for reporting, but as it's included in all appliances by default, it's not surprising that if your setup was susceptible to this bug, then any v16.x TurnKey LXC build would exhibit the same issue.

Add new comment