Hide Forgot
Description of problem: We had a problem recently where a wrong configuration of the NFV profile caused the profile not be loaded during boot (reproducer sequence below). The only place where I could find an indication of the error was in tuned logs. There's nothing in systemd: [root@rhel73-single ~]# systemctl status tuned ● tuned.service - Dynamic System Tuning Daemon Loaded: loaded (/usr/lib/systemd/system/tuned.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2016-10-17 14:49:38 EDT; 29s ago Main PID: 1066 (tuned) CGroup: /system.slice/tuned.service └─1066 /usr/bin/python -Es /usr/sbin/tuned -l -P Oct 17 14:49:37 rhel73-single systemd[1]: Starting Dynamic System Tuning Daemon... Oct 17 14:49:38 rhel73-single systemd[1]: Started Dynamic System Tuning Daemon. [root@rhel73-single ~]# So it feels like tuned is reporting success to systemd, even though it failed to load properly. NOTE: I suspect this issue has always existed. Version-Release number of selected component (if applicable): tuned-2.7.1-4.el7fdb.noarch How reproducible: Steps to Reproduce: 1. Make a mistake to tuned profile configuration. For example, in the case of the NFV profile, write the following to /etc/tuned/realtime-variables.conf for a guest with only 2 vCPUs: isolated_cores=1,3 2. Boot the guest 3. Check the load of the profile has failed during boot: [root@rhel73-single ~]# tuned-adm active No current active profile. [root@rhel73-single ~]# 4. Check systemd status as indicated above
At the moment it's not clear how to fix it. We need to keep D-Bus daemon running to e.g. allow recovery from the Cockpit, so the daemon cannot just exit with the failure and AFAIK there is nothing like running failed state for the systemd service. We will probably have to rewrite the daemon to support state without any active profile and maybe split the main daemon to Tuned service and D-Bus service.
*** Bug 1500508 has been marked as a duplicate of this bug. ***
Note that bug 1500508 as a better description for this issue. Also, maybe we should move this to 7.6 given that this will probably require complex code changes but tuned is in bug fixing only phase now.
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