Hide Forgot
Description of problem: Version-Release number of selected component (if applicable): tuned-2.11.0-5.el7.noarch How reproducible: always on some machines Steps to Reproduce: 1. load balanced profile 2. check logs for ERROR 3. Actual results: :: [ 22:10:57 ] :: [ LOG ] :: === [1mActual profile: balanced[m === :: [ 22:10:57 ] :: [ BEGIN ] :: Running 'tuned-adm profile balanced' :: [ 22:10:59 ] :: [ PASS ] :: Command 'tuned-adm profile balanced' (Expected 0, got 0) :: [ 22:11:02 ] :: [ BEGIN ] :: Running 'tuned-adm active | grep balanced' Current active profile: balanced :: [ 22:11:02 ] :: [ PASS ] :: Command 'tuned-adm active | grep balanced' (Expected 0, got 0) :: [ 22:14:48 ] :: [ FAIL ] :: Current system setting corresponds with selected profile. (Expected 0, got 1) :: [ 22:14:48 ] :: [ BEGIN ] :: Running 'cat /var/log/tuned/tuned.log | grep ERROR' 2019-06-08 22:14:48,391 ERROR tuned.plugins.plugin_modules: verify: failed: 'module 'cpufreq_conservative' is not loaded' :: [ 22:14:48 ] :: [ LOG ] :: Output of 'cat /var/log/tuned/tuned.log | grep ERROR': :: [ 22:14:48 ] :: [ LOG ] :: --------------- OUTPUT START --------------- :: [ 22:14:48 ] :: [ LOG ] :: 2019-06-08 22:14:48,391 ERROR tuned.plugins.plugin_modules: verify: failed: 'module 'cpufreq_conservative' is not loaded' :: [ 22:14:48 ] :: [ LOG ] :: --------------- OUTPUT END --------------- :: [ 22:14:48 ] :: [ PASS ] :: Command 'cat /var/log/tuned/tuned.log | grep ERROR' (Expected 0, got 0) Expected results: Additional info:
Thanks for the report. It's caused by this commit: https://github.com/redhat-performance/tuned/commit/af269d11ae3ef167 The commit adds a line to the balanced profile which tells Tuned to load the cpufreq_conservative kernel module. I believe this is needed on SUSE, because they have it compiled as a module. However in RHEL, we have it built-in in the kernel. I'm not really sure what we should do about this. Normally we would adjust the logging levels so that the message doesn't look as bad in the log, however I don't think that's a good solution here. The log level needs to be at least WARN, so that it gets noticed on systems, where it's relevant (namely SUSE). However if we simply log it as WARN instead of ERROR, it's still going to annoy our users in RHEL, where the message is irelevant. I think the patch should not have been upstreamed in the first place. So I see two possibilities: a) revert the change upstream b) revert the change downstream in RHEL and Fedora There's also a third possibility - ideally, we would detect whether the module needs to be loaded or not. However I don't think this is worth the effort here.
For the record, the errors are harmless.
For the record, Jarda came up with another solution: load the kernel module 'cpufreq_conservative' in the CPU plugin, when necessary - the kernel module is only required by the CPU plugin to set the 'conservative' CPU governor, so the CPU plugin is the logical place to load it.
Red Hat Enterprise Linux version 7 entered the Maintenance Support 1 Phase in August 2019. In this phase only qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available. Other errata advisories may be delivered as appropriate. This bug has been reviewed by Support and Engineering representative and does not meet the inclusion criteria for Maintenance Support 1 Phase. If this issue still exists in newer major version of Red Hat Enterprise Linux, it has been cloned there and work will continue in the cloned bug. For more information about Red Hat Enterprise Linux Lifecycle, please see https://access.redhat.com/support/policy/updates/errata/
Development Management has reviewed and declined this request. You may appeal this decision by using your Red Hat support channels, who will make certain the issue receives the proper prioritization with product and development management. https://www.redhat.com/support/process/production/#howto