I just recently discovered that power profiles are disabled in my laptop (Lenovo, Fedora 41. This must have happened in the last couple of weeks. A bit of web searching later, I see that the power-profile-daemon has been replaced with tuned/tuned-ppd.
systemctl status tuned.service
× tuned.service - Dynamic System Tuning Daemon
Loaded: loaded (/usr/lib/systemd/system/tuned.service; enabled; preset: enabled)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf, 50-keep-warm.conf
Active: failed (Result: exit-code) since Thu 2025-08-28 10:54:07 CEST; 25s ago
Invocation: 30cf9c4b721c47cf92a3665651bd9cf4
Docs: man:tuned(8)
man:tuned.conf(5)
man:tuned-adm(8)
Process: 20050 ExecStart=/usr/sbin/tuned -l -P (code=exited, status=203/EXEC)
Main PID: 20050 (code=exited, status=203/EXEC)
Mem peak: 1M
CPU: 2ms
Aug 28 10:54:07 hostname systemd[1]: Starting tuned.service - Dynamic System Tuning Daemon...
Aug 28 10:54:07 hostname (tuned)[20050]: tuned.service: Failed to execute /usr/sbin/tuned: Permission denied
Aug 28 10:54:07 hostname (tuned)[20050]: tuned.service: Failed at step EXEC spawning /usr/sbin/tuned: Permission denied
Aug 28 10:54:07 hostname systemd[1]: tuned.service: Main process exited, code=exited, status=203/EXEC
Aug 28 10:54:07 hostname systemd[1]: tuned.service: Failed with result 'exit-code'.
Aug 28 10:54:07 hostname systemd[1]: Failed to start tuned.service - Dynamic System Tuning Daemon.
user@hostname:~$ ll /usr/sbin/tuned
-rwxr-xr-x. 1 root root 3965 Feb 3 2025 /usr/sbin/tuned
```
It says the permissions are denied, but the root should be able to execute that file.
Any tips?
Thanks!
Then I’ve run setenforce 0 to disable SELinux temporarily. Seems to have helped, the service starts, the daemon runs properly and power mode selection appears in gnome again.
Might be an exec context issue for the /usr/sbin/tuned ? Not an expert on SELinux particulars.
Happy to provide more details, the issue is reproducible on my system with every reboot since a few days. Hope it helps resolve the issue!
I didn’t see that first reply two weeks ago. But I’ve just checked (after doing a big update yesterday) and everything seems to be working again. So, I guess that’s….good?
Alright so I did all that after upgrading the system - restorecon -v did not make any changes initially, so went ahead and tried semanage -a -t <type> to match the ones you’ve provided and restorecon -v again to set the contexts. Changes were made as expected:
Relabeled /usr/sbin/tuned from system_u:object_r:bin_t:s0 to system_u:object_r:tuned_exec_t:s0
Relabeled /usr/sbin/tuned-ppd from system_u:object_r:bin_t:s0 to system_u:object_r:tuned_ppd_exec_t:s0
Yet, the service still throws the same Permission denied fit:
Sep 11 21:13:19 systemd[1]: Starting tuned.service - Dynamic System Tuning Daemon...
Sep 11 21:13:19 (tuned)[4585]: tuned.service: Unable to locate executable '/usr/sbin/tuned': Permission denied
Sep 11 21:13:19 (tuned)[4585]: tuned.service: Failed at step EXEC spawning /usr/sbin/tuned: Permission denied
Sep 11 21:13:19 systemd[1]: tuned.service: Main process exited, code=exited, status=203/EXEC
Sep 11 21:13:19 systemd[1]: tuned.service: Failed with result 'exit-code'.
Sep 11 21:13:19 systemd[1]: Failed to start tuned.service - Dynamic System Tuning Daemon.
Again, retrying to start after disabling SELinux is successful. I’ve noticed that in my case the /sbin/tuned* binaries are actually symlinks to /bin/tuned*.
I think the issue was introduced lately, I’ve not have this happen to me before, and I usually have my system updated every 2 weeks or so. Using Fedora 42 (just noticed the f41 tag, first time on the forums), kernel 6.16.5-200.fc42.x86_64. Also, I’m running the same tuned version as you tuned-2.25.1-2.fc42.noarch
$ systemctl status tuned.service
● tuned.service - Dynamic System Tuning Daemon
Loaded: loaded (/usr/lib/systemd/system/tuned.service; enabled; preset: enabled)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: active (running) since Tue 2025-09-09 10:57:38 BST; 2 days ago
Invocation: 1049bf84d8744f789854534202eca9fb
Docs: man:tuned(8)
man:tuned.conf(5)
man:tuned-adm(8)
Main PID: 1492 (tuned)
Tasks: 4 (limit: 76456)
Memory: 22.8M (peak: 26.6M)
CPU: 52.330s
CGroup: /system.slice/tuned.service
└─1492 /usr/bin/python3 -Es /usr/sbin/tuned -l -P
Sep 09 10:57:38 atlas systemd[1]: Starting tuned.service - Dynamic System Tuning Daemon...
Sep 09 10:57:38 atlas systemd[1]: Started tuned.service - Dynamic System Tuning Daemon.
can you see if there are more logs?
journalctl -b --unit=tuned.service
Have you tried relabeling the complete file system by the way? There could be other files that tuned is not able to access. That worked in this other similar post:
Tell you what, an autorelabel with /.autorelabel did not help. Running fixfiles by fixfiles -R tuned,tuned-ppd restore only returned 1k. I also tried a restorecon on /usr entirely, no luck. Logs look the same as they did previously:
Sep 12 12:12:18 systemd[1]: Starting tuned.service - Dynamic System Tuning Daemon...
Sep 12 12:12:18 (tuned)[9559]: tuned.service: Unable to locate executable '/usr/sbin/tuned': Permission denied
Sep 12 12:12:18 (tuned)[9559]: tuned.service: Failed at step EXEC spawning /usr/sbin/tuned: Permission denied
Sep 12 12:12:18 systemd[1]: tuned.service: Main process exited, code=exited, status=203/EXEC
Sep 12 12:12:18 systemd[1]: tuned.service: Failed with result 'exit-code'.
Sep 12 12:12:18 systemd[1]: Failed to start tuned.service - Dynamic System Tuning Daemon.
Only ditching SELinux entirely seems to help so far for the issue.
rpm -V should verify all files against the known metadata in the rpm anyway. rpm -V tuned returns nothing here.
You could always try reinstalling the packages, but i’d be very surprised if that changed anything.
Are you able to run the tuned binary manually, as root?
tuned -D -d -l -P
We should also enable the -D flag to get more info in the logs. Maybe that’ll tell us what file it is unable to access. How about editing the service file /usr/lib/systemd/system/tuned.service and adding the flag to the command there, and then restarting your system to see if the logs have more info in them?
Have you edited any of the config files or anything too? Maybe it’s unable to read those?
Had some more time to tinker and ran the reinstall filesystem command, here’s what I got:
[3/4] Reinstalling filesystem-0:3.18-47 100% | 929.1 KiB/s | 212.8 KiB | 00m00s
/usr/sbin cannot be merged yet, found /usr/sbin/capsh
/usr/sbin cannot be merged yet, found /usr/sbin/capsh
libcap is a dependency of systemd, and cannot be simply reinstalled:
Failed to resolve the transaction:
Problem: installed package systemd-257.9-2.fc42.x86_64 requires libcap.so.2()(64bit), but none of the providers can be installed
- conflicting requests
- problem with installed package
Moreover libcap appears to be the thing that helps systemd resolve permissions. What would you do with this lead?
@ankursinha any clues? Do you get the same sbin merge error on /usr/sbin/capsh?
EDIT: readlink /usr/sbin tells me the directory is not a symlink, but rather the files inside are. This might be the root cause of the issue here.
I’ve figured out a stopgap way to fix this. None of the options helped, even after successfully reinstalling the filesystem, relabeling, etc. Instead of trying to resolve the symlink issues I’ve changed the /usr/lib/systemd/system/tuned.service definition to:
But I’ve just checked (after doing a big update yesterday) and everything seems to be working again. So, I guess that’s….good?