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'>))
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.