Bug 1421286 - tuned doesn't update grub.cfg when stopped by systemd
tuned doesn't update grub.cfg when stopped by systemd
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: tuned (Show other bugs)
7.4
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Jaroslav Škarvada
Tereza Cerna
: Patch, Upstream
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-02-10 16:30 EST by Luiz Capitulino
Modified: 2017-08-01 08:32 EDT (History)
3 users (show)

See Also:
Fixed In Version: tuned-2.8.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-01 08:32:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Luiz Capitulino 2017-02-10 16:30:04 EST
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 11:09:20 EDT
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 11:16:00 EDT
(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 11:25:53 EDT
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 11:39:00 EDT
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 11:44:58 EDT
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 06:36:14 EDT
It seems clear from the systemctl documentation and it was also confirmed by systemd guys.
Comment 7 Jaroslav Škarvada 2017-04-01 06:44:27 EDT
Upstream commit fixing the problem:
https://github.com/redhat-performance/tuned/commit/df9aa2f5c46e4db08a077081ca15b6da541b4514
Comment 8 Luiz Capitulino 2017-04-03 08:51:22 EDT
Very nice!
Comment 10 Tereza Cerna 2017-04-26 06:08:23 EDT
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
Comment 11 errata-xmlrpc 2017-08-01 08:32:51 EDT
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

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