no error message when failing to apply profile while starting tuned

[insatomcat]

Hello,

When tuned fails to apply a profile while the service is started, we get a legitimate error message and appropriate return code (here I try to isolate 20 cpus but I only have 16):

root@w:~# systemctl stop tuned
root@w:~# systemctl start tuned
root@w:~# grep ^isol /etc/tuned/realtime-virtual-host-variables.conf
isolated_cores=1-20
isolate_managed_irq=Y
root@w:~# tuned-adm profile realtime-virtual-host
Unable to switch profile: Cannot load profile(s) 'realtime-virtual-host': Assertion 'isolated_cores contains online CPU(s)' failed.

But if the service is stopped for whatever reason (in my case, it's because it's stopped by default on freshly deployed servers, and enabled only on specific ones), then tuned starts the service, fails to apply the profile, but says otherwise:

root@w:~# systemctl start tuned
root@w:~# tuned-adm off
root@w:~# tuned-adm active
No current active profile.
root@w:~# systemctl stop tuned
root@w:~# grep ^isol /etc/tuned/realtime-virtual-host-variables.conf
isolated_cores=1-20
isolate_managed_irq=Y
root@w:~# tuned-adm profile realtime-virtual-host
Cannot talk to TuneD daemon via DBus. Is TuneD daemon running?
Trying to (re)start tuned...
TuneD (re)started, changes applied.
root@w:~# tuned-adm active
No current active profile.
root@w:~#

As you can see, there is no mention of tuned failing to apply the profile (although it did fail), we get a nice "changes applied" message with a returncode=0 so we could think that the profile was applied.

Thanks.

[yarda]

I think this could be improved. It now doesn't wait for the result and just restarts the service. I think it could wait for the DBus signal a display the result. Of course it will work only with the D-Bus.

[zacikpa]

There is another solution that would work even without DBus, but I'm not sure whether it wouldn't cause problems elsewhere - when TuneD starts without any profile successfully applied, /etc/tuned/active_profile remains as it was before starting TuneD. In this case, TuneD is running with no profile applied, but /etc/tuned/active_profile contains realtime-virtual-host-variables.

We could erase the content of the file after an unsuccessful profile application here, and then the admin could check whether the contents of the file correspond to the desired profile after restarting TuneD.

[yarda]

There is another solution that would work even without DBus, but I'm not sure whether it wouldn't cause problems elsewhere - when TuneD starts without any profile successfully applied, /etc/tuned/active_profile remains as it was before starting TuneD. In this case, TuneD is running with no profile applied, but /etc/tuned/active_profile contains realtime-virtual-host-variables.

We could erase the content of the file after an unsuccessful profile application here, and then the admin could check whether the contents of the file correspond to the desired profile after restarting TuneD.

This is probably easier to implement, maybe even cleaner, but tuned-adm should signal this, otherwise it may lead to confusion.

[zacikpa]

There is another solution that would work even without DBus, but I'm not sure whether it wouldn't cause problems elsewhere - when TuneD starts without any profile successfully applied, /etc/tuned/active_profile remains as it was before starting TuneD. In this case, TuneD is running with no profile applied, but /etc/tuned/active_profile contains realtime-virtual-host-variables.
We could erase the content of the file after an unsuccessful profile application here, and then the admin could check whether the contents of the file correspond to the desired profile after restarting TuneD.

This is probably easier to implement, maybe even cleaner, but tuned-adm should signal this, otherwise it may lead to confusion.

What do you mean by "signal"? I was thinking something along the lines of https://github.com/redhat-performance/tuned/compare/master...zacikpa:tuned:tuned-adm-profile-check?expand=1.

[yarda]

Probably got it, but the tuned-adm profile should still wait for the D-Bus profile_changed signal, because without the --async option it normally returns after the profile is applied. With the restart the command returns immediately, not after the profile is applied.