Bug 2028701
| Summary: | tlp actively breaks power-profiles-daemon when installed | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | DH <dave> |
| Component: | tlp | Assignee: | Jeremy Newton <alexjnewt> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 35 | CC: | alexjnewt, bnocera, jgrulich, me, mkyral, nnailat, oliver, rdieter, than |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| URL: | https://retrace.fedoraproject.org/faf/reports/bthash/5d22e19db594a41da754f3a415fdea7ee66abe5c | ||
| Whiteboard: | abrt_hash:3d590e53c6cc0d537b6a5f4f739e171a7f93ce9b;VARIANT_ID=kde; | ||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-08-25 14:34:06 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Reassigning this to powerdevil, it shouldn't be forking out a command-line utility to access a daemon that's not running. The actual error (which is irrelevant and shouldn't trigger a bug report) is fixed upstream: https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/merge_requests/95 I don't know why power-profiles-daemon.service can't be started, but it's likely that you have a conflicting daemon installed. In any case, Plasma shouldn't be offering you to change the power profile if power-profiles-daemon isn't running. A little more context: On fresh install of Fedora 35 yesterday, powerprofilesctl worked as expected from command line. Since letting the Discover application upgrade all the packages it wanted to, powerprofilesctl is 100% not working. So, the manual scripts I wrote to call powerprofilesctl are also failing. Current installed powerprofilesctl is 0.10.1. Manually installing power-profile-daemon package 0.10.1-2.fc35.x86_64 has made no change, powerprofilesctl always dumps a traceback. I'll post exact fail messages in my next post... Failure messages when manually invoking powerprofilesctl from command line:
$ powerprofilesctl
Couldn't get Profiles: <class 'ReferenceError'>
Traceback (most recent call last):
File "/usr/bin/powerprofilesctl", line 124, in get_profiles_property
profiles = proxy.Get('(ss)', 'net.hadess.PowerProfiles', prop)
File "/usr/lib/python3.10/site-packages/gi/overrides/Gio.py", line 349, in __call__
result = self.dbus_proxy.call_sync(self.method_name, arg_variant,
gi.repository.GLib.Error: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer. (3)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/powerprofilesctl", line 132, in _list
profiles = get_profiles_property('Profiles')
File "/usr/bin/powerprofilesctl", line 126, in get_profiles_property
raise ReferenceError
ReferenceError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/powerprofilesctl", line 262, in <module>
main()
File "/usr/bin/powerprofilesctl", line 218, in main
_list()
File "/usr/bin/powerprofilesctl", line 138, in _list
raise SystemError
SystemError
$ $ powerprofilesctl get
Traceback (most recent call last):
File "/usr/bin/powerprofilesctl", line 262, in <module>
main()
File "/usr/bin/powerprofilesctl", line 211, in main
_get()
File "/usr/bin/powerprofilesctl", line 106, in _get
profile = proxy.Get('(ss)', 'net.hadess.PowerProfiles', 'ActiveProfile')
File "/usr/lib/python3.10/site-packages/gi/overrides/Gio.py", line 349, in __call__
result = self.dbus_proxy.call_sync(self.method_name, arg_variant,
gi.repository.GLib.Error: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer. (3)
$$ powerprofilesctl list
Couldn't get Profiles: <class 'ReferenceError'>
Traceback (most recent call last):
File "/usr/bin/powerprofilesctl", line 124, in get_profiles_property
profiles = proxy.Get('(ss)', 'net.hadess.PowerProfiles', prop)
File "/usr/lib/python3.10/site-packages/gi/overrides/Gio.py", line 349, in __call__
result = self.dbus_proxy.call_sync(self.method_name, arg_variant,
gi.repository.GLib.Error: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer. (3)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/powerprofilesctl", line 132, in _list
profiles = get_profiles_property('Profiles')
File "/usr/bin/powerprofilesctl", line 126, in get_profiles_property
raise ReferenceError
ReferenceError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/powerprofilesctl", line 262, in <module>
main()
File "/usr/bin/powerprofilesctl", line 218, in main
_list()
File "/usr/bin/powerprofilesctl", line 138, in _list
raise SystemError
SystemError
$ sudo systemctl daemon-reload
$ sudo systemctl list-units --all | grep -i power
● power-profiles-daemon.service masked inactive dead power-profiles-daemon.service
upower.service loaded active running Daemon for power management
system-dbus\x2d:1.12\x2dorg.kde.powerdevil.backlighthelper.slice loaded active active Slice /system/dbus-:1.12-org.kde.powerdevil.backlighthelper
system-dbus\x2d:1.12\x2dorg.kde.powerdevil.chargethresholdhelper.slice loaded active active Slice /system/dbus-:1.12-org.kde.powerdevil.chargethresholdhelper
system-dbus\x2d:1.12\x2dorg.kde.powerdevil.discretegpuhelper.slice loaded active active Slice /system/dbus-:1.12-org.kde.powerdevil.discretegpuhelper
$ cd /
$ sudo find -noleaf -iname power-profiles-daemon
./var/lib/power-profiles-daemon
So, is there a system service that I am missing, needs reinstalled, etc. No idea why a simple upgrade would break powerprofilesctl, nor why manually installing power-profiles-daemon would result in an empty/masked service definition to be registered?!?
More context: Related report: https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues/58 In the comments of that report, the OP is asked if they had installed tlp. My answer is yes, I have installed tlp and tlp-rdw manually. Removing those packages makes powerprofilesctl work again. Why does tlp break powerprofilesctl? What would it take to make these play nicely? Supposed fix: https://bodhi.fedoraproject.org/updates/FEDORA-2021-311cb47cbc running the recommended $ sudo dnf upgrade --advisory=FEDORA-2021-311cb47cbc made no difference (power-profiles-daemon conflicts with tlp because tlp might be changing settings that
power-profiles-daemon or the firmware rely on, leading to bad performance, or broken
settings. But given what tlp does in its scriptlets, this is moot)
tlp actively disables power-profiles-daemon and breaks the system remembering the rfkill
state across runs.
tlp has absolutely no right of doing this, and installing tlp shouldn't break already
installed applications. I wanted to avoid an all-out escalation of package conflicts
rather than service conflicts, but I'll have no choice but doing that if you don't
fix your package to not muck around other packages.
$ rpm -qp --scripts tlp-1.4.0-2.fc35.noarch.rpm
postinstall scriptlet (using /bin/sh):
if [ $1 -eq 1 ] && [ -x "/usr/lib/systemd/systemd-update-helper" ]; then
# Initial installation
/usr/lib/systemd/systemd-update-helper install-system-units tlp.service || :
fi
systemctl mask systemd-rfkill.service
systemctl mask power-profiles-daemon.service
preuninstall scriptlet (using /bin/sh):
if [ $1 -eq 0 ] && [ -x "/usr/lib/systemd/systemd-update-helper" ]; then
# Package removal, not upgrade
/usr/lib/systemd/systemd-update-helper remove-system-units tlp.service || :
fi
postuninstall scriptlet (using /bin/sh):
if [ $1 -ge 1 ] && [ -x "/usr/lib/systemd/systemd-update-helper" ]; then
# Package upgrade, not uninstall
/usr/lib/systemd/systemd-update-helper mark-restart-system-units tlp.service || :
fi
if [ $1 -eq 0 ] ; then
systemctl unmask systemd-rfkill.service
systemctl unmask power-profiles-daemon.service
fi
*** Bug 2028982 has been marked as a duplicate of this bug. *** I've filed an issue for FESCO to handle as I didn't get any answers to this bug in a month: https://pagure.io/fesco/issue/2725 tlp should never be disabling services it doesn't own. Sorry I looked over this before and was busy due to the holidays. I'll fix it shortly. FEDORA-2022-89facbca19 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-89facbca19 FEDORA-2022-89facbca19 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-89facbca19` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-89facbca19 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. I'm afraid that this will leave users who have installed older versions of tlp with a broken systemd-rfkill and power-profiles-daemon service. The package needs to handle unmasking those services when upgrading from older versions of tlp. Gotcha, does adding the following to %post seem sufficient?
if [ $1 -eq 2 ] ; then
systemctl unmask systemd-rfkill.service
systemctl unmask power-profiles-daemon.service
fi
Or did you have something else in mind?
(In reply to Jeremy Newton from comment #18) > Gotcha, does adding the following to %post seem sufficient? > > if [ $1 -eq 2 ] ; then > systemctl unmask systemd-rfkill.service > systemctl unmask power-profiles-daemon.service > fi > > Or did you have something else in mind? It's in the right ballpark, but I can't offer a review on this, I would need to 1) check the RPM manual to see whether that's the right comparison to use, and 2) to test it. I'm afraid I don't have the resources to do that. (In reply to Bastien Nocera from comment #19) > (In reply to Jeremy Newton from comment #18) > > Gotcha, does adding the following to %post seem sufficient? > > > > if [ $1 -eq 2 ] ; then > > systemctl unmask systemd-rfkill.service > > systemctl unmask power-profiles-daemon.service > > fi > > > > Or did you have something else in mind? > > It's in the right ballpark, but I can't offer a review on this, I would need > to 1) check the RPM manual to see whether that's the right comparison to > use, and 2) to test it. I'm afraid I don't have the resources to do that. Ok understood because: 1) I took that from the manual :) 2) I will test it myself momentarily The only concern is that I would like at least one more tester before I push anything. I might just disable the autopush to be safe if I'm not feeling too confident. FEDORA-2022-869660660c has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2022-869660660c FEDORA-2022-4d3f456d01 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-4d3f456d01 FEDORA-2022-869660660c has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-869660660c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-869660660c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2022-4d3f456d01 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-4d3f456d01` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-4d3f456d01 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. Fixed in rawhide. I'm abandoning the package so I won't be able to fix in Fedora 35. The fix was pushed to updates testing but I never had time to actually investigate if it actually worked. If someone else takes the package, feel free to reopen. |
Description of problem: Changing KDE window decoration settings, KDE Plasma Shell crashed and restarted itself. Version-Release number of selected component: power-profiles-daemon-0.10.1-2.fc35 Additional info: reporter: libreport-2.15.2 cgroup: 0::/user.slice/user-1000.slice/user/background.slice/plasma-powerdevil.service cmdline: /usr/bin/python3 /usr/bin/powerprofilesctl set performance crash_function: __call__ exception_type: gi.repository.GLib.GError executable: /usr/bin/powerprofilesctl interpreter: python3-3.10.0-1.fc35.x86_64 kernel: 5.15.5-200.fc35.x86_64 runlevel: N 5 type: Python3 uid: 1000 Truncated backtrace: Gio.py:349:__call__:gi.repository.GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer. (3) Traceback (most recent call last): File "/usr/bin/powerprofilesctl", line 262, in <module> main() File "/usr/bin/powerprofilesctl", line 216, in main _set(args[0]) File "/usr/bin/powerprofilesctl", line 111, in _set proxy.Set('(ssv)', File "/usr/lib/python3.10/site-packages/gi/overrides/Gio.py", line 349, in __call__ result = self.dbus_proxy.call_sync(self.method_name, arg_variant, gi.repository.GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer. (3) Local variables in innermost frame: self: <gi.overrides.Gio._DBusProxyMethodCall object at 0x7f3819a54fa0> args: ('net.hadess.PowerProfiles', 'ActiveProfile', GLib.Variant('s', 'performance')) kwargs: {} signature: '(ssv)' arg_variant: GLib.Variant('(ssv)', ('net.hadess.PowerProfiles', 'ActiveProfile', <'performance'>))