| Summary: | PowerDevil causing laptop reboots | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | git+kde <git+kde> |
| Component: | Power management & brightness | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | grave | CC: | nate, nicolas.fella |
| Priority: | NOR | ||
| Version First Reported In: | 6.4.5 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
git+kde@john.me.tz
2025-10-13 18:24:45 UTC
Is there an actual crash? As in, does `coredumpctl --reverse` show any crash logs for org_kde_powerdevil, kwin_wayland, or plasmashell? There are none directly attributed to powerdevil. There are several for plasmashell, but I think these were for a different issue. Specifically, the shell was crashing during media playback via "Strawberry Music Player" related to the "Media Player" tray icon. I disabled that tray entry and those crashes went away. I submitted an automatic crash report for this, but I can open another bug if you recommend that I do so. None of the timestamps from the coredump seem to align with the powerdevil issue that we are discussing in this issue: ``` coredumpctl --reverse TIME PID UID GID SIG COREFILE EXE SIZE Sun 2025-10-12 15:24:25 MDT 13273 1000 1000 SIGSEGV present /usr/bin/plasmashell 22.6M Sun 2025-10-12 15:24:17 MDT 13157 1000 1000 SIGSEGV present /usr/bin/plasmashell 22.4M Sun 2025-10-12 15:24:08 MDT 13019 1000 1000 SIGSEGV present /usr/bin/plasmashell 23.2M Sun 2025-10-12 15:23:58 MDT 12897 1000 1000 SIGSEGV present /usr/bin/plasmashell 22.1M Sun 2025-10-12 15:23:45 MDT 12773 1000 1000 SIGSEGV present /usr/bin/plasmashell 21.8M Sun 2025-10-12 15:23:37 MDT 12649 1000 1000 SIGSEGV present /usr/bin/plasmashell 22.1M Sun 2025-10-12 15:23:25 MDT 12484 1000 1000 SIGSEGV present /usr/bin/plasmashell 21.4M Sun 2025-10-12 15:23:17 MDT 12316 1000 1000 SIGSEGV present /usr/bin/plasmashell 21.6M Sun 2025-10-12 15:23:17 MDT 10161 1000 1000 SIGABRT present /usr/bin/maliit-keyboard 5.1M Sun 2025-10-12 15:23:05 MDT 5726 1000 1000 SIGSEGV present /usr/bin/plasmashell 32.7M Sun 2025-10-12 15:11:48 MDT 2206 1000 1000 SIGABRT present /usr/bin/maliit-keyboard 4.9M Sun 2025-10-12 14:59:51 MDT 4533 1000 1000 SIGSEGV present /usr/bin/plasmashell 21.3M Sun 2025-10-12 14:59:42 MDT 4395 1000 1000 SIGSEGV present /usr/bin/plasmashell 21.3M Sun 2025-10-12 14:59:32 MDT 4237 1000 1000 SIGSEGV present /usr/bin/plasmashell 22.2M Sun 2025-10-12 14:59:24 MDT 2327 1000 1000 SIGSEGV present /usr/bin/plasmashell 29.5M ``` It seems to essentially just trigger a power cut. Thanks! With reboot you mean it does an actual full system reboot? Or just the session crashes and restarts? (In reply to Nicolas Fella from comment #3) > With reboot you mean it does an actual full system reboot? Or just the > session crashes and restarts? Full system reboot, yes. On a different machine it might just be a halt. This laptop had quirks even under windows where it would reboot after being instructed to shutdown. Does the same happen when you run "systemctl suspend"? (In reply to Nicolas Fella from comment #5) > Does the same happen when you run "systemctl suspend"? Hi! Thanks for your continued help! The behaviour does appear to be identical (or nearly identical). I expected that manually running the command would have resulted in something being logged, but it looks like the last couple of minutes of the journal might be missing. The auth event for running the requested command with 'sudo', nor was there anything for the command itself. Perhaps this is just a result of the journal buffer not immediately being written to disk? The last logged event was an automatic update about 2 minutes prior to 'suspend': ``` Oct 14 22:50:12 aurora systemd[1]: Starting brew-upgrade.service - Upgrade Brew packages... Oct 14 22:50:12 aurora systemd[1]: Starting sysstat-collect.service - system activity accounting tool... Oct 14 22:50:12 aurora systemd[1]: sysstat-collect.service: Deactivated successfully. Oct 14 22:50:12 aurora systemd[1]: Finished sysstat-collect.service - system activity accounting tool. Oct 14 22:50:12 aurora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=> Oct 14 22:50:12 aurora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=?> Oct 14 22:50:16 aurora bash[6252]: Error: No such keg: /home/linuxbrew/.linuxbrew/Cellar/systemd Oct 14 22:50:19 aurora bash[6518]: Error: No such keg: /home/linuxbrew/.linuxbrew/Cellar/dbus Oct 14 22:50:21 aurora bash[6776]: Error: No such keg: /home/linuxbrew/.linuxbrew/Cellar/python Oct 14 22:50:24 aurora bash[7036]: Error: No such keg: /home/linuxbrew/.linuxbrew/Cellar/gsettings Oct 14 22:50:26 aurora bash[7310]: Error: No such keg: /home/linuxbrew/.linuxbrew/Cellar/bash Oct 14 22:50:28 aurora bash[7568]: Error: No such keg: /home/linuxbrew/.linuxbrew/Cellar/rpm Oct 14 22:50:28 aurora systemd[1]: brew-upgrade.service: Deactivated successfully. Oct 14 22:50:28 aurora systemd[1]: Finished brew-upgrade.service - Upgrade Brew packages. Oct 14 22:50:28 aurora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=brew-upgrade comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? t> Oct 14 22:50:28 aurora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=brew-upgrade comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? te> Oct 14 22:50:28 aurora systemd[1]: brew-upgrade.service: Consumed 16.862s CPU time, 224.8M memory peak. ``` Not to speak out of turn on the diagnosis, but it seems to be the case that the actual reboot might be a significantly lower-level problem with the hardware/firmware. If you agree with that, I think that the focus of this bug should become the fact that even when I have all idle sleep behaviours disabled in the settings, the system seems to still be getting the suspend signal after 5 minutes. I wasn't too bothered with just having powerdevil disabled since I don't really need any automatic sleep behaviours. However, I realised today that it is also responsible for setting the backlight brightness in response to the function keys, so having it disabled is causing other inconveniences. > Not to speak out of turn on the diagnosis, but it seems to be the case that the actual reboot might be a significantly lower-level problem with the hardware/firmware I do agree with that, it looks like your hardware is pretty severely broken > I think that the focus of this bug should become the fact that even when I have all idle sleep behaviours disabled in the settings, the system seems to still be getting the suspend signal after 5 minutes. Make sure you you disable suspend for all profiles (battery, AC, low battery). Adding this to .config/powerdevilrc should do it [AC][SuspendAndShutdown] AutoSuspendAction=0 [Battery][SuspendAndShutdown] AutoSuspendAction=0 [LowBattery][SuspendAndShutdown] AutoSuspendAction=0 > I do agree with that, it looks like your hardware is pretty severely broken I won't disagree there, but I think that it is a level of broken that is possible to work around! :) > Make sure you you disable suspend for all profiles (battery, AC, low > battery). Adding this to .config/powerdevilrc should do it > > [AC][SuspendAndShutdown] > AutoSuspendAction=0 > > [Battery][SuspendAndShutdown] > AutoSuspendAction=0 > > [LowBattery][SuspendAndShutdown] > AutoSuspendAction=0 Those settings were already present. Here is the modified date of the file and all of its contents: ``` $ ls -alh .config/powerdevilrc -rw-------. 1 rebecca rebecca 754 Oct 12 20:46 .config/powerdevilrc $ cat .config/powerdevilrc [AC][Display] DimDisplayIdleTimeoutSec=120 DisplayBrightness=20 TurnOffDisplayIdleTimeoutSec=300 UseProfileSpecificDisplayBrightness=true [AC][Keyboard] KeyboardBrightness=0 UseProfileSpecificKeyboardBrightness=true [AC][SuspendAndShutdown] AutoSuspendAction=0 LidAction=0 PowerButtonAction=0 [Battery][Display] DimDisplayIdleTimeoutSec=-1 DimDisplayWhenIdle=false DisplayBrightness=10 [Battery][Keyboard] KeyboardBrightness=0 [Battery][SuspendAndShutdown] AutoSuspendAction=0 LidAction=0 PowerButtonAction=0 [BatteryManagement] BatteryCriticalAction=0 [LowBattery][Display] DisplayBrightness=5 [LowBattery][Keyboard] UseProfileSpecificKeyboardBrightness=true [LowBattery][SuspendAndShutdown] AutoSuspendAction=0 LidAction=0 PowerButtonAction=0 ``` The AutoSuspendActions are all 0, but I notice that there is a 5 minute timeout for `TurnOffDisplayIdleTimeoutSec=300`. Is it safe to try setting that to 0? I checked and yes `TurnOffDisplayIdleTimeoutSec=0` is a bad idea, it causes immediate timeouts rather than none. In my case that meant that I needed to boot from a recovery ISO to revert that change because it would crash before I could do anything. For now I have extended it to `TurnOffDisplayIdleTimeoutSec=86400` for all modes and it has been idling happily for > 10 minutes. I'm now going to experiment with re-enabling some other idle modes. 🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone! 🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME. |