|Summary:||Performance profile change from none to balanced although cancel the action|
|Product:||Red Hat Enterprise Linux 7||Reporter:||wanghui <huiwa>|
|Component:||tuned||Assignee:||Jaroslav Škarvada <jskarvad>|
|Status:||CLOSED WONTFIX||QA Contact:||qe-baseos-daemons|
|Version:||7.2||CC:||bugs, cshao, dperpeet, huzhao, jeder, jskarvad, leiwang, olysonek, stefw, tcerna, thozza, weiwang, yaniwang|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2019-12-09 08:43:44 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
|Bug Blocks:||1329957, 1400961|
Description wanghui 2016-05-17 08:23:54 UTC
Comment 2 Stef Walter 2016-05-25 06:49:37 UTC
Can you check if tuned was started during the course of this bug? Did the system start with tuned not running, and after the bug occurs tuned is running?
Comment 4 Dominik Perpeet 2016-07-06 08:11:50 UTC
Stef, I think this was fixed in https://github.com/cockpit-project/cockpit/pull/4623 - Cockpit 0.112. Can you please confirm this?
Comment 5 Stef Walter 2016-07-06 10:33:37 UTC
Nope it wasn't. I'm not sure this should be assigned to me. It's either a tuned or a tuned defaults bug. In order to use DBus to ask tuned what its configuration is, tuned must be started. If started it enables the default tuned performance profile (until the next boot). So either tuned behavior must be changed, or the RHEV-H default tuned configuration should be set to disabled so that starting tuned has no effect on the performance profile. I don't think this should be assigned to me. Reassigning, and changing the component.
Comment 6 Stef Walter 2016-07-06 10:35:14 UTC
Assigning back to the original assignee, Ryan. I think a call needs to be made at a higher level, which of the above fixes are desirable. It doesn't seem that this is related specifically to Cockpit.
Comment 7 Jaroslav Škarvada 2016-07-08 12:50:08 UTC
Tuned sets default profile during its first start according to the config file where are rules matching default profiles against products/architectures. We can add rule for your product for Tuned to set it right or it is possible to bypass the autodetection by writing any profile name to: /etc/tuned/active_profile before Tuned is started. Once this file exists and contains valid profile name, Tuned will not try to autodetect and set the default profile. Previously we detected the default profile in the spec %post by calling 'tuned-adm recommend', but it turned out it was not the right thing, because the image could be installed on different platform than it is later run at, that's why the default profile is auto detected during the first start. Tuned service is run by default, thus the DBus API should be available and the profile should be already auto-detected. There is DBus method active_profile() which should return the name of currently active profile. There is also the DBus method recommend_profile() which will return the default profile name as autodetected (i.e. it will run the autodetection and return the profile name, it will not change active profile and it's the same routine that Tuned use during its first start). In case Tuned is not running and DBus API is not available you can still find out the default profile for your platform by executing 'tuned-adm recommend' (which is again the same routine as Tuned use during its first start but it doesnt' set the profile). Tuned-adm can also return current active profile (similarly as DBus call active_profile()) but even without DBus available, this can be accomplished by executing 'tuned-adm active'. Hope this helps.
Comment 8 Jaroslav Škarvada 2019-12-06 15:56:33 UTC
I think it should be fixed by: https://github.com/cockpit-project/cockpit/pull/4623 https://github.com/redhat-performance/tuned/commit/5d8ef2c0095e999107574ebfb86e735bc048756e In Tuned it's fixed in tuned-2.13.0 (RHEL-8.2).
Comment 9 Tomáš Hozza 2019-12-09 08:43:37 UTC
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. The issue is fixed in in newer major version of Red Hat Enterprise Linux. For more information about Red Hat Enterprise Linux Lifecycle, please see https://access.redhat.com/support/policy/updates/errata#Maintenance_Support_1_Phase.
Comment 10 RHEL Program Management 2019-12-09 08:43:44 UTC
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