You are not logged in.
Hi,
I've got a problem with power management.
every now and then, when I press the power button - which is configured to go to standby - shuts down the system instead.
I observed the following: this happens exactly when the screen does not go to standby any more but stays on forever.
So, since this behavior appeared yesterday again I tried the following:
Got to start menu, select standby - works fine.
Today I opened power management which tells me
"Energieeinstellungen können nicht geladen werden. Der Energieverwaltungsdienst scheint nicht zu laufen."
I googled this and tried the following
$ systemctl status upower
upower.service - Daemon for power management
Loaded: loaded (/usr/lib/systemd/system/upower.service; disabled; preset: disabled)
Active: active (running) since Fri 2025-06-06 21:12:26 CEST; 6 days ago
Invocation: 713a3fcaff564eb199bb56fb0a35870f
Docs: man:upowerd(8)
Main PID: 1059 (upowerd)
Tasks: 4 (limit: 57565)
Memory: 5.3M (peak: 6.8M)
CPU: 289ms
CGroup: /system.slice/upower.service
└─1059 /usr/lib/upowerd
Jun 06 21:12:26 JPT systemd[1]: Starting Daemon for power management...
Jun 06 21:12:26 JPT systemd[1]: Started Daemon for power management.
$ systemctl enable upower
Created symlink '/etc/systemd/system/graphical.target.wants/upower.service' → '/usr/lib/systemd/system/upower.service'.
$ systemctl status upower
upower.service - Daemon for power management
Loaded: loaded (/usr/lib/systemd/system/upower.service; enabled; preset: disabled)
Active: active (running) since Fri 2025-06-06 21:12:26 CEST; 6 days ago
Invocation: 713a3fcaff564eb199bb56fb0a35870f
Docs: man:upowerd(8)
Main PID: 1059 (upowerd)
Tasks: 4 (limit: 57565)
Memory: 5.3M (peak: 6.8M)
CPU: 289ms
CGroup: /system.slice/upower.service
└─1059 /usr/lib/upowerd
Jun 06 21:12:26 JPT systemd[1]: Starting Daemon for power management...
Jun 06 21:12:26 JPT systemd[1]: Started Daemon for power management.
This did not help. As it was running already. Restarting did not help either.
Ive got a few questions:
- why are a lot of services disabled even if I explicitly enabled them in the past? (repeatedly had this with avahi, which is really annoying when you want to add network printers/scanners)
- what does "preset: disabled" mean?
- how could I find out what's wrong?
I suspected that upgrading the kernel turns a suspend into a reboot. But there wasn't a system update since last boot. Only a few programs updated (firefox, thunderbird, signal)
thank you very much.
Offline
every now and then, when I press the power button - which is configured to go to standby - shuts down the system instead.
Today I opened power management which tells me
"Energieeinstellungen können nicht geladen werden. Der Energieverwaltungsdienst scheint nicht zu laufen."
Don't rely on some session daemon to intercept fatal events, configure it (also) in /etc/systemd/logind.conf (or a drop in override configlet)
- why are a lot of services disabled even if I explicitly enabled them in the past? (repeatedly had this with avahi, which is really annoying when you want to add network printers/scanners)
Because somebody or something disabled them?
- what does "preset: disabled" mean?
https://bbs.archlinux.org/viewtopic.php?id=264854
https://bbs.archlinux.org/viewtopic.php … 5#p2180685
https://bbs.archlinux.org/viewtopic.php?id=293001
Offline
Thanks seth
I need you to clarify a bit.
every now and then, when I press the power button - which is configured to go to standby - shuts down the system instead.
Today I opened power management which tells me
"Energieeinstellungen können nicht geladen werden. Der Energieverwaltungsdienst scheint nicht zu laufen."Don't rely on some session daemon to intercept fatal events, configure it (also) in /etc/systemd/logind.conf (or a drop in override configlet)
I don't understand, what do you mean?
- why are a lot of services disabled even if I explicitly enabled them in the past? (repeatedly had this with avahi, which is really annoying when you want to add network printers/scanners)
Because somebody or something disabled them?
That should be obvious. But who or what could have disabled them? Wasn't me.
Offline
I don't understand, what do you mean?
The ACPI event is by default handled by systemd, session dameons like powerdevil (I assume you're on KDE) can intercept and override that handling, but if that daemon for whatever reason fails, systemd kicks in w/ the default handling.
So the advice is to also make sure that systemd will not handle that event in an undesired way (which is done via that file, nb. you'll have to reboot or reload systemd-logind in order to apply that)
And inb4: no, that's not a very smart construct, but systemd implements a state machine w/ limited ability, so the userspace daemon cannot just reconfigure systemd and acpid isn't the default because systemd mission creep.
But who or what could have disabled them? Wasn't me.
Gremlins?
Enabling a service happens via symlink out of the sphere that's supposed to be altered by the package/manager
avahi conflicts w/ systemd-resolved's mdns responder, so maybe you semi-accidentally deactivated it in reconfiguration efforts in that context?
But without the situation imminent it's hard to tell what's actually going on.
Offline
Thanks, the hint to powerdevil set me on the right track.
It wasn't running.
I started it using this https://forum.endeavouros.com/t/solutio … g-up/14540
Let's see, if it works again now.
That leaves the questions:
- how do I find out why it crashed in the first place?
- is there any tool to show the status of KDE daemons like systemctl does?
Offline
1. https://wiki.archlinux.org/title/Core_d … _core_dump
2. "kcmshell kded" ? might be kcmshell6
Offline
Great.
I added
[Coredump]
ProcessSizeMax=4G
Compress=yes
Storage=external
Let see if it produces something.
would be nice, if it was limited to KDE daemons, but I didn't find a quick solution to that.
Offline
Are there no present entries in
coredumpctl
?
Offline
Yes there are, but no coredumps.
the date is probably when it stopped working.
coredumpctl list /usr/lib/org_kde_powerdevil
TIME PID UID GID SIG COREFILE EXE SIZE
Tue 2025-02-11 11:54:23 CET 2820 1000 1001 SIGABRT missing /usr/lib/org_kde_powerdevil -
Tue 2025-02-11 11:54:25 CET 2875 1000 1001 SIGABRT missing /usr/lib/org_kde_powerdevil -
Tue 2025-02-11 11:54:25 CET 2951 1000 1001 SIGABRT missing /usr/lib/org_kde_powerdevil -
Tue 2025-02-11 11:54:25 CET 3022 1000 1001 SIGABRT missing /usr/lib/org_kde_powerdevil -
Tue 2025-02-11 11:54:25 CET 3080 1000 1001 SIGABRT missing /usr/lib/org_kde_powerdevil -
Last edited by JPT48 (2025-06-21 15:58:35)
Offline