Description of problem: When I start the computer the process rngd starts to use 100% of the CPU immediately. Version-Release number of selected component (if applicable): rngd 6.7 How reproducible: Every time the computer starts. Steps to Reproduce: 1. Start the computer. 2. Run top. Actual results: The process rngd uses 100% of the CPU. Expected results I don't now were this process is used for but I expect it to have no impact on my machine. Additional info: Is use Fedora *Silverblue* 30 Version: 30.20190809.0 (2019-08-09T00:48:42Z)
This is the output of systemctl status rngd : rngd.service - Hardware RNG Entropy Gatherer Daemon Loaded: loaded (/usr/lib/systemd/system/rngd.service; enabled; vendor preset: enabled) Active: inactive (dead) since Sun 2019-08-11 14:02:07 CEST; 46s ago Process: 934 ExecStart=/sbin/rngd -f (code=killed, signal=TERM) Main PID: 934 (code=killed, signal=TERM) aug 11 14:01:12 DellXPS13 systemd[1]: Started Hardware RNG Entropy Gatherer Daemon. aug 11 14:01:12 DellXPS13 rngd[934]: Initalizing available sources aug 11 14:01:12 DellXPS13 rngd[934]: Initalizing entropy source hwrng aug 11 14:01:12 DellXPS13 rngd[934]: Enabling RDSEED rng support aug 11 14:01:12 DellXPS13 rngd[934]: Initalizing entropy source rdrand aug 11 14:02:07 DellXPS13 systemd[1]: rngd.service: Main process exited, code=killed, status=15/TERM aug 11 14:02:07 DellXPS13 systemd[1]: rngd.service: Succeeded. I didn’t know what the process rngd did until I ran top in order to find out what my system was doing. I didn’t explicitly enable it.
I killed the process after starting up the computer.
I disabled the service rngd with 'systemctl disable --now rngd'. It solves the problem for now.
There is a similar issue here: https://bugzilla.redhat.com/show_bug.cgi?id=1744315
Today I did a fresh install of Fedora *Silverblue* 31 and I noticed that this problem is still present. I disabled the service rndg with 'systemctl disable --now rngd'. Changed the product version from 30 to 31. Let me know if there is something I could do/test.
Scott, I resolved the issue on a Lenovo T490s by disabling TPM at BIOS/UEFI level. Can you try that?
Hi Mikel, Thanks for the advice! I completely disabled TPM in the BIOS/UEFI and restarted the system but sadly enough the process RNGD immediately again started to use 100% of the CPU :-(. I disabled to service again with'systemctl disable --now rngd'. You are working on this issue? Regards, Verhoeckx (real name)
Hi Verhoeckx, I'm sorry but I'm not working on the issue, I'm a RH employee but I don't work on Fedora or any of the components that may be failing here. I found the root cause for my issue and wanted to check if yours was the same issue. I created a report for my issue in https://bugzilla.redhat.com/show_bug.cgi?id=1770021 Regards, Mikel
No problem! Hopefully the problem will be solved somewhere in the near future! Regards, Verhoeckx
(In reply to Mikel Olasagasti from comment #6) > Scott, I resolved the issue on a Lenovo T490s by disabling TPM at BIOS/UEFI > level. Can you try that? Hey Mikel, you're a life-saver. This issue came up for me too after a recent Kernel upgrade and I was hoping it'd go away with the F31 upgrade. It didn't. Disabling TPM in BIOS/UEFI fixed the issue for me though. I'm on a X390 Thinkpad.
I just upgraded to kernel 5.4.7 and got bit by this bug on Fedora 31. The process rngd is using 100% of one of my cpu cores and I get an "Unexpected system error" in kernel-core from abrt upon logging in to Gnome. I tried disabling TPM in BIOS and it did not help. There are no issues when booting into 5.3.16 kernel. I am on an Acer Aspire VX5-591G laptop. If there is any additional info I can supply please let me know.
Confirmed here on a Clevo N151CU-derived notebook. Doesn't happen on any other hardware I own. rng-tools-6.7-3.fc31.x86_64 kernel-5.4.8-200.fc31.x86_64 Not tried disabling TPM. Disabling rngd for now.
(In reply to James Ettle from comment #12) > Not tried disabling TPM. Disabling rngd for now. Disabling TPM in the firmware config *does* things on this particular machine. Interesting to note when TPM is enabled, it generates around 5000 wakeups/s and doesn't allow the CPU to downclock.
I think I've run into this one too — though in my case, restarting rngd is enough to fix the issue. In my case, it looks like it just sorta spins trying to initialise some of its sources of entropy or something. An hour after boot: > ● rngd.service - Hardware RNG Entropy Gatherer Daemon > Loaded: loaded (/usr/lib/systemd/system/rngd.service; enabled; vendor preset: enabled) > Active: active (running) since Sat 2020-01-11 18:01:53 AEDT; 1h 6min ago > Main PID: 1661 (rngd) > Tasks: 5 (limit: 18775) > Memory: 2.0M > CPU: 1h 6min 19.930s > CGroup: /system.slice/rngd.service > └─1661 /sbin/rngd -f > > Jan 11 18:01:53 krombopulos systemd[1]: Started Hardware RNG Entropy Gatherer Daemon. > Jan 11 18:01:53 krombopulos rngd[1661]: Initalizing available sources > Jan 11 18:01:53 krombopulos rngd[1661]: Initalizing entropy source hwrng > Jan 11 18:01:53 krombopulos rngd[1661]: Enabling RDSEED rng support > Jan 11 18:01:53 krombopulos rngd[1661]: Initalizing entropy source rdrand After a systemctl restart: > ● rngd.service - Hardware RNG Entropy Gatherer Daemon > Loaded: loaded (/usr/lib/systemd/system/rngd.service; enabled; vendor preset: enabled) > Active: active (running) since Sat 2020-01-11 19:08:28 AEDT; 14s ago > Main PID: 56972 (rngd) > Tasks: 5 (limit: 18775) > Memory: 1.4M > CPU: 20.410s > CGroup: /system.slice/rngd.service > └─56972 /sbin/rngd -f > > Jan 11 19:08:28 krombopulos systemd[1]: Started Hardware RNG Entropy Gatherer Daemon. > Jan 11 19:08:28 krombopulos rngd[56972]: Initalizing available sources > Jan 11 19:08:28 krombopulos rngd[56972]: Initalizing entropy source hwrng > Jan 11 19:08:28 krombopulos rngd[56972]: Enabling RDSEED rng support > Jan 11 19:08:28 krombopulos rngd[56972]: Initalizing entropy source rdrand > Jan 11 19:08:31 krombopulos rngd[56972]: Initalizing AES buffer > Jan 11 19:08:31 krombopulos rngd[56972]: Enabling JITTER rng support > Jan 11 19:08:31 krombopulos rngd[56972]: Initalizing entropy source jitter > Jan 11 19:08:31 krombopulos rngd[56972]: PKCS11 Engine /usr/lib64/opensc-pkcs11.so Error: No such file or directory > Jan 11 19:08:31 krombopulos rngd[56972]: Failed to init entropy source pkcs11
Ah, I should have noted: 5.3.16-300.fc31.x86_64 on an XPS 13 9380, BIOS versions 1.8.0
Bug appears to have been squashed for me in kernel 5.4.10.
Not fixed for me in kernel 5.4.10. For my affected machine: kernel: tpm_tis IFX0785:00: 2.0 TPM (device-id 0x1B, rev-id 22)
Happening on Fedora 31: 5.4.7-200.fc31.x86_64 rngd[3911866]: Entropy Generation is slow, consider tuning/adding sources systemctl status rngd * rngd.service - Hardware RNG Entropy Gatherer Daemon Loaded: loaded (/usr/lib/systemd/system/rngd.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2020-01-29 11:29:07 EST; 2min 21s ago Main PID: 3911866 (rngd) Tasks: 5 (limit: 57886) Memory: 1.5M CPU: 31.372s CGroup: /system.slice/rngd.service `-3911866 /sbin/rngd -f Jan 29 11:29:13 ourdomain.edu rngd[3911866]: Entropy Generation is slow, consider tuning/adding sources
The default configuration of rngd.service 1.) Is explicitely started in foreground mode, instead of the default daemon mode (-f (foreground) flag present) - seems like there's a bug wihen run in daemon mode, the daemon dies (or exits gracefully) for no apparent reason - no log. 2.) default configuration expects rngd to search for *some* standard entropy sources and use those, but this may result "not enough entropy" messages -- adding entropy sources is as simple as a.) list available sources with "rngd --list" b.) add desired sources to /usr/lib/systemd/system/rngd.service ExecStart line using the name in parenthesis Example: rngd --list Entropy sources that are available but disabled 1: TPM RNG Device (tpm) 4: NIST Network Entropy Beacon (nist) Available and enabled entropy sources: 5: JITTER Entropy generator (jitter) Edit rngd.service to use favourite source(s): ExecStart=/sbin/rngd -f -n jitter -n nist Note warnings associated with using nist ! Assuming you are only using this as a source of entropy (which is how rngd is using it), you can safely ignore those warnings (I think)
Which is to say that including nist as a (but not the only) source of entropy is *probably* totally safe.
It seems this report is for rng-tools, not for jitterentropy-rngd. Changed component
could you please reproduce the issue and, while it is occurring, become root and run the following command: rngd -ff -o rngd.strace -p `pidof rngd` Then attach the rngd.strace file to this bz also if you could run this command (also as root) journalctl > journal.txt and attach journal.txt here it would be helpful
sorry the line I wanted you to run should actually be: strace -ff -o rngd.strace -p `pidof rngd`
Hello Neil, I tried to re-enable the service rngd but I think something went wrong: [verhoeckx@xps13 ~]$ sudo systemctl enable --now rngd Created symlink /etc/systemd/system/multi-user.target.wants/rngd.service → /usr/lib/systemd/system/rngd.service. [verhoeckx@xps13 ~]$ sudo systemctl status rngd ● rngd.service - Hardware RNG Entropy Gatherer Daemon Loaded: loaded (/usr/lib/systemd/system/rngd.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2020-07-06 11:15:20 CEST; 5s ago Main PID: 10365 (rngd) Tasks: 5 (limit: 18705) Memory: 1.9M CPU: 9.889s CGroup: /system.slice/rngd.service └─10365 /sbin/rngd -f Jul 06 11:15:20 xps13 rngd[10365]: Initializing available sources Jul 06 11:15:20 xps13 rngd[10365]: [hwrng ]: Initialization Failed Jul 06 11:15:20 xps13 rngd[10365]: [rdrand]: Enabling RDSEED rng support Jul 06 11:15:20 xps13 rngd[10365]: [rdrand]: Initialized Jul 06 11:15:20 xps13 rngd[10365]: [jitter]: Initializing AES buffer Jul 06 11:15:20 xps13 rngd[10365]: [jitter]: Unable to obtain AES key, disabling AES in JITTER source Jul 06 11:15:20 xps13 rngd[10365]: [jitter]: Enabling JITTER rng support Jul 06 11:15:20 xps13 rngd[10365]: [jitter]: Initialized Jul 06 11:15:20 xps13 rngd[10365]: [pkcs11]: PKCS11 Engine /usr/lib64/opensc-pkcs11.so Error: No such file or directory Jul 06 11:15:20 xps13 rngd[10365]: [pkcs11]: Initialization Failed When I reboot my laptop and run 'top | grep rngd' I don't get any output. So I guess it's still not running?
if you don't have an rngd process after a reboot, no its not running. I'm not sure why that would be, you would have to provide the journal log to make any determination as to what happened there. That seems like a systemd issue
Created attachment 1700060 [details] journal.txt This is my journal file of the last 2 days (I removed everything older than 2 days).
Created attachment 1700061 [details] Result of strace -ff -o rngd.strace -p `pidof rngd` I run the following command: sudo strace -ff -o rngd.strace -p `pidof rngd` Result: strace: Process 836 attached with 5 threads + the five files in the zip-file.
Hopefully the above files are helpful! If you need anything else: let me know!
It helps a bit, but unfortunately, given the strace files you've sent, it appears that rngd should be using none of the cpu, not 100% of it, as each thread you recorded was blocked on a system call (which is to be expected in the nominal case, when the entropy pool is full). Did you note that rngd was using 100% cpu during this time? As for the journal, it appears that rngd started just fine on boot, so you should have seen an rngd process, which doesn't seem to match what you said in comment 24. Can you clarify? Did abrt note some crash in the process at a later time after the journal was captured?
Hello Neil, Mmm, I think the problem is solved because the process rndg is running and I don't notice any cpu usage! 1. I enabled the service rndg last monday. 2. When I run 'ps -ef | grep rngd' I see a process is running. root 834 1 0 13:03 ? 00:00:18 /sbin/rngd -f 3. When I run 'ps -p 834 -o %cpu,%mem,cmd' I see only 0.2% cpu usage. %CPU %MEM CMD 0.2 0.0 /sbin/rngd -f Conclusion: problem solved :-) I think the upgrade to Fedora 32 solved the problem? Thanks for thinking along! What shall we do with this bug report? Verhoeckx
Thats possible. There was a problem with jitterentropy back around the F30 time frame, but it got fixed pretty quickly, if you were somehow on that older version, that would explain it. closing as CURRENTRELEASE