Bug 1421286 - tuned doesn't update grub.cfg when stopped by systemd
Summary: tuned doesn't update grub.cfg when stopped by systemd
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: tuned
Version: 7.4
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Jaroslav Škarvada
QA Contact: Tereza Cerna
Depends On:
TreeView+ depends on / blocked
Reported: 2017-02-10 21:30 UTC by Luiz Capitulino
Modified: 2017-08-01 12:32 UTC (History)
3 users (show)

Fixed In Version: tuned-2.8.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-08-01 12:32:51 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2102 0 normal SHIPPED_LIVE tuned bug fix and enhancement update 2017-08-01 16:07:33 UTC

Description Luiz Capitulino 2017-02-10 21:30:04 UTC
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

Comment 1 Jaroslav Škarvada 2017-03-30 15:09:20 UTC
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.

Comment 2 Jaroslav Škarvada 2017-03-30 15:16:00 UTC
(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.

Comment 3 Luiz Capitulino 2017-03-30 15:25:53 UTC
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

Comment 4 Jaroslav Škarvada 2017-03-30 15:39:00 UTC
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.

Comment 5 Luiz Capitulino 2017-03-30 15:44:58 UTC
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.

Comment 6 Jaroslav Škarvada 2017-04-01 10:36:14 UTC
It seems clear from the systemctl documentation and it was also confirmed by systemd guys.

Comment 7 Jaroslav Škarvada 2017-04-01 10:44:27 UTC
Upstream commit fixing the problem:

Comment 8 Luiz Capitulino 2017-04-03 12:51:22 UTC
Very nice!

Comment 10 Tereza Cerna 2017-04-26 10:08:23 UTC
Verified in:

:: [   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

Comment 11 errata-xmlrpc 2017-08-01 12:32:51 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.