Bug 1421286

Summary:	tuned doesn't update grub.cfg when stopped by systemd
Product:	Red Hat Enterprise Linux 7	Reporter:	Luiz Capitulino <lcapitulino>
Component:	tuned	Assignee:	Jaroslav Škarvada <jskarvad>
Status:	CLOSED ERRATA	QA Contact:	Tereza Cerna <tcerna>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.4	CC:	jeder, jskarvad, tcerna
Target Milestone:	rc	Keywords:	Patch, Upstream
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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 12:32:51 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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:
https://github.com/redhat-performance/tuned/commit/df9aa2f5c46e4db08a077081ca15b6da541b4514

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

https://access.redhat.com/errata/RHBA-2017:2102