There is a regression if run rngd as unprivileged user(bz#1692435?). rngd has no permission to write to "/proc/sys/kernel/random/write_wakeup_threshold". It always reports "unable to adjust write_wakeup_threshold: Permission denied". [root@ip-10-116-2-80 ec2-user]# dmesg|grep -i rngd [ 11.275042] systemd[1]: rngd.service: Current command vanished from the unit file, execution of the command list won't be resumed. [ 11.297211] systemd[1]: rngd.service: Main process exited, code=killed, status=6/ABRT [ 11.306484] systemd[1]: rngd.service: Failed with result 'signal'. [root@ip-10-116-2-52 proc]# grep 988 /etc/passwd rngd:x:988:988:Random Number Generator Daemon:/var/lib/rngd:/sbin/nologin [root@ip-10-116-2-80 ec2-user]# 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 2019-11-25 06:03:24 UTC; 25s ago Main PID: 772 (rngd) Tasks: 3 (limit: 26213) Memory: 3.6M CGroup: /system.slice/rngd.service └─772 /sbin/rngd -f Nov 25 06:03:24 ip-10-116-1-193.us-west-2.compute.internal systemd[1]: Started Hardware RNG Entropy Gatherer Daemon. Nov 25 06:03:24 ip-10-116-1-193.us-west-2.compute.internal rngd[772]: Initializing available sources Nov 25 06:03:24 ip-10-116-1-193.us-west-2.compute.internal rngd[772]: Failed to init entropy source hwrng Nov 25 06:03:24 ip-10-116-1-193.us-west-2.compute.internal rngd[772]: Enabling RDSEED rng support Nov 25 06:03:24 ip-10-116-1-193.us-west-2.compute.internal rngd[772]: Initializing entropy source rdrand Nov 25 06:03:28 ip-10-116-2-80.us-west-2.compute.internal rngd[772]: Initializing AES buffer Nov 25 06:03:28 ip-10-116-2-80.us-west-2.compute.internal rngd[772]: Enabling JITTER rng support Nov 25 06:03:28 ip-10-116-2-80.us-west-2.compute.internal rngd[772]: Initializing entropy source jitter Nov 25 06:03:28 ip-10-116-2-80.us-west-2.compute.internal rngd[772]: unable to adjust write_wakeup_threshold: Permission denied [root@ip-10-116-2-52 proc]# ls -l /proc/sys/kernel/random/write_wakeup_threshold -rw-r--r--. 1 root root 0 Nov 25 05:24 /proc/sys/kernel/random/write_wakeup_threshold [root@ip-10-116-2-80 ec2-user]# rpm -qa|grep rng rng-tools-6.8-1.el8.x86_64 Version-Release number of selected component (if applicable): RHEL Version: RHEL8.2(4.18.0-151.el8.x86_64) How reproducible: 100% Steps to Reproduce: 1. Start a RHEL8.2 in aws. 2. check rngd.service status Actual results: unable to adjust write_wakeup_threshold: Permission denied Expected results: No such failure Additional info: - No such failure in RHEL8.1(rng-tools-6.6-2.el8.x86_64, run as root)
This isnt a regression, the service still works just fine, it just issues a warning about not being able to adjust the write wakeup threshold because we're running as a non-root user. There is a onetime service added to RHEL which does this on rngd's behalf. We could remove the warning, but then users who have legitimate permission issues, and no other service to do this setting for them would not be aware of the issue. I suppose I could augment the warning to indicate that its not fatal, but I cant remove it entirely. Is that acceptable?
(In reply to Neil Horman from comment #1) > This isnt a regression, the service still works just fine, it just issues a > warning about not being able to adjust the write wakeup threshold because > we're running as a non-root user. There is a onetime service added to RHEL > which does this on rngd's behalf. We could remove the warning, but then > users who have legitimate permission issues, and no other service to do this > setting for them would not be aware of the issue. I suppose I could augment > the warning to indicate that its not fatal, but I cant remove it entirely. > Is that acceptable? Yes, I see the rngd service is in running state and it is acceptable to make the warning more clear. Do you have any idea of dmesg output? Seems it is another problem. If yes, I can filed a separate bug for it. # dmesg|grep -i rngd [ 11.275042] systemd[1]: rngd.service: Current command vanished from the unit file, execution of the command list won't be resumed. [ 11.297211] systemd[1]: rngd.service: Main process exited, code=killed, status=6/ABRT [ 11.306484] systemd[1]: rngd.service: Failed with result 'signal'.
(In reply to Xiao, Liang from comment #2) > (In reply to Neil Horman from comment #1) > > This isnt a regression, the service still works just fine, it just issues a > > warning about not being able to adjust the write wakeup threshold because > > we're running as a non-root user. There is a onetime service added to RHEL > > which does this on rngd's behalf. We could remove the warning, but then > > users who have legitimate permission issues, and no other service to do this > > setting for them would not be aware of the issue. I suppose I could augment > > the warning to indicate that its not fatal, but I cant remove it entirely. > > Is that acceptable? > > Yes, I see the rngd service is in running state and it is acceptable to make > the warning more clear. > > Do you have any idea of dmesg output? Seems it is another problem. If yes, I > can filed a separate bug for it. > > # dmesg|grep -i rngd > [ 11.275042] systemd[1]: rngd.service: Current command vanished from the > unit file, execution of the command list won't be resumed. > [ 11.297211] systemd[1]: rngd.service: Main process exited, code=killed, > status=6/ABRT > [ 11.306484] systemd[1]: rngd.service: Failed with result 'signal'. Let's keep this bug for making log more clear. I filed another bug 1776710 for tracking that rngd takes longer time in boot up.
Why would we keep this bug open? Whats it going to clarify if we're not going to change anything?
(In reply to Neil Horman from comment #4) > Why would we keep this bug open? Whats it going to clarify if we're not > going to change anything? I suspect you will do some change to highlight that the "Permission denied" error is not fatal or just a harmless warning. So I said keep this open for tracking your change.
I think I found a way around this. I can add a special value to fill_watermark to indicate that no watermark should be set, and use that to avoid the warning entirely. I'm going to fix this as part of 1776710 *** This bug has been marked as a duplicate of bug 1776710 ***