Red Hat Bugzilla – Bug 1421286
tuned doesn't update grub.cfg when stopped by systemd
Last modified: 2017-08-01 08:32:51 EDT
Description of problem: When tuned is stopped and disabled by systemd, like: # systemctl stop tuned # systemctl disable tuned The grub.cfg file won't get updated, meaning that it will still contain the tuned_params= tuning set by tuned. So, if you reboot those settings will still be applied. This doesn't happen when you switch profiles for example, which is the correct behavior. Version-Release number of selected component (if applicable): tuned-2.7.1-4.el7fdb.noarch How reproducible: Steps to Reproduce: 1. Apply a profile that adds tuned_params= in grub.cfg (eg. realtime-host-profile) 2. Stop and disable tuned daemon: # systemctl stop tuned # systemctl disable tuned 3. Check that grub.cfg still contains tuned_params= tuning
It's intended because with the systemd it's impossible to distinguish whether Tuned was stopped due to system reboot or manually. If we revert the grub.cfg on stop the tuning will be missing on normal reboots. Regarding the 'systemctl disable tuned' I have to check whether we could add some hook there. For now I think we can only document this behavior.
(In reply to Jaroslav Škarvada from comment #1) > Regarding the 'systemctl disable tuned' I have to check whether we could add > some hook there. > Unfortunately it doesn't seem to be hookable.
I think we have to scalate this to systemd then. There's two possible solutions: 1. Add a hook for system disable This should solve our issue completely. There's two possible scenarios: A. User stops tuned but doesn't disable it In this case, the systemctl disable hook won't trig and grub.cfg won't be updated. This is not a problem, because if the user reboots tuned will still be started and the expected behavior is that the configuration will be fully applied. B. User stops tuned and disables it This is the case where grub.cfg is updated, and we're all good. 2. Add a way for daemons to distinguish between a stop and a reboot I don't know how tuned stops daemons, but this can be done with different signals for each operation or having a file somewhere daemons can read to determine if it's a stop or a system shutdown
Maybe I have found workaround: We could execute the following command on stop: systemctl is-system-running and check it for the string "stopping", which means the SIGTERM was sent due to shutdown/reboot.
Cool, but I think it's a good idea to confirm with systemd people that it's OK to do that. I mean, we have to confirm that it's guaranteed that systemctl is-system-running will be "stopping" before killing the daemons (and that the meaning will be "stopping daemon due to shutdown/reboot"). Otherwise, a race condition is possible and that would be a hell to debug.
It seems clear from the systemctl documentation and it was also confirmed by systemd guys.
Upstream commit fixing the problem: https://github.com/redhat-performance/tuned/commit/df9aa2f5c46e4db08a077081ca15b6da541b4514
Very nice!
Verified in: tuned-2.8.0-2.el7.noarch PASS :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: Test :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ PASS ] :: Command 'tuned-adm profile my_profile' (Expected 0, got 0) :: [ PASS ] :: Command 'tuned-adm active' (Expected 0, got 0) :: [ PASS ] :: Command 'grep 'tuned_params=' /boot/grub2/grub.cfg | grep nosoftlockup' (Expected 0, got 0) :: [ PASS ] :: Command 'systemctl stop tuned' (Expected 0, got 0) :: [ PASS ] :: Command 'systemctl disable tuned' (Expected 0, got 0) :: [ PASS ] :: Command 'grep 'tuned_params=' /boot/grub2/grub.cfg | grep nosoftlockup' (Expected 1, got 1) :: [ LOG ] :: Duration: 3s :: [ LOG ] :: Assertions: 6 good, 0 bad :: [ PASS ] :: RESULT: Test
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2102