Bug 1224202

https://build.opensuse.org/package/rdiff/openSUSE:Factory/tuned?linkrev=base&rev=38

Reverted tuned to not have this conflict.

@badshah
Your submitrequest I approved:
https://build.opensuse.org/request/show/1166521

has been reverted by Dominique due to package conflicts in update case (afaik).

I do not like the hard conflict forbidding the whole installation.
It's the wrong approach.

In the request you wrote:
> Then a curious user installs tuned (which as of now, goes through swimmingly) > but cannot figure out just why they cannot enable tuned.service.
This is absolutely ok (to install both packages). The bug would be to more obvious show the user the real conflict: systemd services
at whatever user interface.

I see the problem with tlp which reacts on systemd/dbus/network manager events. This is not done with a background (systemd) service, but it seems they put their scripts at certain places to get them executed on e.g. USB plugin/battery change and similar.
This is not nice and ugly to handle. The tlp maintainer suggested (for the debian guys, but they seem to not have added the change yet):
https://github.com/linrunner/TLP/commit/6a9388e1af95051a90a33b4014af1158dfa241f6
Interesting is that they already handle the systemd-rfkill.service the same way (disable in case of tlp installation, enable in case of tlp de-installation).

Hm on the other hand side, it's not a good idea to enable/disable system(d) services behind the users back via package (de-)install.

I just tried out what happens if one tries to start a service conflicting service, e.g. startung tlp if tuned is already running.
systemd then simply shuts down tuned service. What is missing (IMO) is a clear message that the service has been shut down, because the conflicting service tlp has been started.

Strange is that I can enable (not start, just enable) both:
systemctl is-enabled tuned tlp
enabled
enabled

Long story short, we have IMO 2 issues here:
- Better (or more obvious/logged) systemd behaviour handling conflicting
  services
- TLP must not get active without its service. The kernel should set reasonable defaults (for AC/USB removing/adding and similar). If the user wants to override them tlp should only do this via its service (if enabled..).

Is it correct that TLP is the (only) package modifying system behavior based on events and not on a service process aka daemon bases?
Whatabout adding the Conflict there, in the tlp package:
Conflicts: tuned power-profile-daemon

The user still may have to decide which package to get rid of in case of update conflicts. But this looks more correct.
And I would tell the tlp maintainer about this (do not auto-modify system without a (tlp-)service behind).

partially already done:

```
> zypper info --conflicts tlp

Information for package tlp:
----------------------------
Repository     : Main Repository (OSS)
Name           : tlp
Version        : 1.6.1-1.3
Arch           : noarch
Vendor         : openSUSE
…
Conflicts      : [2]
    power-profiles-daemon
    laptop-mode-tools
```

(In reply to Thomas Renninger from comment #2)
> @badshah
> Your submitrequest I approved:
> https://build.opensuse.org/request/show/1166521
> 
> has been reverted by Dominique due to package conflicts in update case
> (afaik).

Yes, I see. I think the mistake has been adding both tuned and p-p-d to he default install patterns which has resulted in every TW system having these multiple conflicting services installed for no sensible reason.

> 
> I do not like the hard conflict forbidding the whole installation.
> It's the wrong approach.

I disagree. Services do not tell the user they conflict, the only way to tell them users thus is when they manually want to install, say, `tuned` when p-p-d is already installed in the system (as in the user specifically runs `zypper in tuned` or similar). That was my idea anyway.

Unfortunately, we seem to have already installed both packages on users' systems without anyone asking for either specifically, and I can see upgrades will run into problems as a result. Sigh...

> 
> In the request you wrote:
> > Then a curious user installs tuned (which as of now, goes through swimmingly) > but cannot figure out just why they cannot enable tuned.service.
> This is absolutely ok (to install both packages). The bug would be to more
> obvious show the user the real conflict: systemd services
> at whatever user interface.
> 
> I see the problem with tlp which reacts on systemd/dbus/network manager
> events. This is not done with a background (systemd) service, but it seems
> they put their scripts at certain places to get them executed on e.g. USB
> plugin/battery change and similar.
> This is not nice and ugly to handle. The tlp maintainer suggested (for the
> debian guys, but they seem to not have added the change yet):
> https://github.com/linrunner/TLP/commit/
> 6a9388e1af95051a90a33b4014af1158dfa241f6
> Interesting is that they already handle the systemd-rfkill.service the same
> way (disable in case of tlp installation, enable in case of tlp
> de-installation).
> 
> Hm on the other hand side, it's not a good idea to enable/disable system(d)
> services behind the users back via package (de-)install.
> 
> I just tried out what happens if one tries to start a service conflicting
> service, e.g. startung tlp if tuned is already running.
> systemd then simply shuts down tuned service. What is missing (IMO) is a
> clear message that the service has been shut down, because the conflicting
> service tlp has been started.

Yes, my belief was — still is — that showing the user the explicit conflict at the package level made it clear that these three (tlp, tuned, p-p-d) do indeed provide conflicting services. This is esp, important for the lack of a better way to show the conflict explicitly when enabling two or more services (for example).

I guess, to get around the upgrade issue, we are choosing to live with the mistake of letting tuned and p-p-d installed by default on a system without a user knowing why e.g. tuned service cannot be enabled (because p-p-d is already running), etc.

For tlp, where the problem is more egregious, I shall send an sr (there is an unrelated pending sr to the devel-prj for which I'll wait) that will add the conflicts against tuned as well.

Is there anything else that I can help with as part of the solution to this bug (given that the conflicts in tuned has been reverted already)?

Finally, I would, if nothing else, strongly suggest choosing one out of the three and recommending it consistently as part of our installable patterns. At present, as Dominique has noted, we add each of the three as part of a very commonly used default pattern. In my opinion, that is quite wrong.

Thanks and best wishes.

Thanks Atri for looking into these details!

I'd concentrate on the 2 issues I mentioned in comment #3:
1. Systemd service conflicts must be made more obvious
2. TLP (or others) must not set any HW/systems parameters statically, e.g. at install time or when HW is (un-)plugged or similar. Setting up HW the way it is most convenient for the majority of the users is the job of the kernel or the kernel module serving the specific HW. So whatever TLP is setting by default (also all event driven things like what happens by default if USB/battery is unplugged or platform suspend or whatsoever) should be submitted to the corresponding kernel part and totally vanish from TLP.
All user specifics which want to override these defaults can then go into whatever power/performance/... profiles getting activated via whatever service of whatever package...

I try to get 1. discussed with our systemd maintainer(s). It should be easy to get an additional syslog message mainlaine like:
systemctl start tuned
   ...
   tlp service stopped to conflict with started tuned service

It's probably harder to get something mainline like:
Do not allow enablement (not starting) of conflicting services. But IMO this should be done, but there might be reasons why enabling conflicting services is possible.

(In reply to Thomas Renninger from comment #7)
> Thanks Atri for looking into these details!
> 
> I'd concentrate on the 2 issues I mentioned in comment #3:
> 1. Systemd service conflicts must be made more obvious
> 2. TLP (or others) must not set any HW/systems parameters statically, e.g.
> at install time or when HW is (un-)plugged or similar. Setting up HW the way
> it is most convenient for the majority of the users is the job of the kernel
> or the kernel module serving the specific HW. So whatever TLP is setting by
> default (also all event driven things like what happens by default if
> USB/battery is unplugged or platform suspend or whatsoever) should be
> submitted to the corresponding kernel part and totally vanish from TLP.
> All user specifics which want to override these defaults can then go into
> whatever power/performance/... profiles getting activated via whatever
> service of whatever package...
> 
> I try to get 1. discussed with our systemd maintainer(s). It should be easy
> to get an additional syslog message mainlaine like:
> systemctl start tuned
>    ...
>    tlp service stopped to conflict with started tuned service
> 

I think that would be wonderful, and, in my opinion, sufficient. Many thanks.

For tlp specifically, I think because of its nature, we should only make it a user-asked install — drop it from all patterns — and make it conflict with the other two (p-p-d and tuned). I use it — and tlp-ui, which I also maintain — myself, and it seems to me to be the best at what it does — reduce battery usage on laptop, setup and disable charging thresholds, so on — but I would not recommend anyone installing it without knowing what they are doing.

I looked somewhat deeper into tlp and partly into power-profile-daemon.

About tlp and:
> but I would not recommend anyone installing it without knowing what they are
> doing.
Yep, this one is just setting things...
I guess it's not that bad on anything laptop based, but the tool should never get used on an Enterprise server by accident...

Not sure, but I could not find anything in power-profiles-daemon as well which is going to set things back?

tuned afaik can do that, yep here it is:
---
When you switch to another profile or deactivate *TuneD*, all changes made to the system settings by the previous profile revert back to their original state.
---

For power-profiles-daemon which is also profile based and it even has "finalize" callbacks which are called when the process (service?) exits, it only seem to free objects/memory there. The tool would need enhancements and save states it could modify in the the init function and the set it back again in the "finalize" function.

One may want to tell them, but this is out of scope for this issue.
Hmm, I wonder why this power-profiles-daemon exist at all. It has the same concept as tuned, but has much less functionality.
Hm, tuned is more server oriented with it's DB profiles, etc.. It even has a powersave-battery-profile (same as powersave profile), but it's probably not actively swtiched to it when running on battery. It also misses the suspend/resume callbacks..., Sigh.

I submitted tlp with:
Conflicts: tuned

https://build.opensuse.org/request/show/1175902

If tlp really is part of default install for Tumbleweed I also think this should not be the case. But this would be a product manager issue, I'll ask.
Let's close this one.

So should I keep obsolete packages or remove tuned or tlp

nvm i got it

Crosslink forum discussion that is linking this ticket https://forums.opensuse.org/t/tlp-conflict-with-tuned/175203

*** Bug 1225218 has been marked as a duplicate of this bug. ***

*** Bug 1226403 has been marked as a duplicate of this bug. ***