Bug 1336684

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?

Stef, I think this was fixed in https://github.com/cockpit-project/cockpit/pull/4623 - Cockpit 0.112.

Can you please confirm this?

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.

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.

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.

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).

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.

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