upower does not start on rawhide: Sep 04 15:57:24 localhost-live systemd[1]: Starting Daemon for power management... Sep 04 15:57:24 localhost-live audit[2054]: AVC avc: denied { create } for pid=2054 comm="(upowerd)" name="upower" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:devicekit_var_lib_t:s0 tclass=dir permissive=0 Sep 04 15:57:24 localhost-live systemd[2054]: upower.service: Failed to set up special execution directory in /var/lib: Permission denied Sep 04 15:57:24 localhost-live systemd[2054]: upower.service: Failed at step STATE_DIRECTORY spawning /usr/libexec/upowerd: Permission denied Sep 04 15:57:24 localhost-live systemd[1]: upower.service: Main process exited, code=exited, status=238/STATE_DIRECTORY Sep 04 15:57:24 localhost-live systemd[1]: upower.service: Failed with result 'exit-code'. Sep 04 15:57:24 localhost-live systemd[1]: Failed to start Daemon for power management. I believe upower was changed to create the directory on demand rather than shipping it in the package.
UPower 0.99.11[1] indeed changed to let systemd create /var/lib/upower[2] I followed that change in the UPower spec and marked that dir as "%ghost"[3] Should have thought about SELinux and file a bug myself immediately, sorry about that. [1] https://gitlab.freedesktop.org/upower/upower/-/tags/UPOWER_0_99_11 [2] https://gitlab.freedesktop.org/upower/upower/blob/e1548bba61206a05bbc318b3d49ae24571755ac6/src/upower.service.in#L17 [2] https://src.fedoraproject.org/rpms/upower/c/8a7fe7d60ef7f8700bf8cbd6da2d324ff067fdd5?branch=master
commit 293e262dfeb15666b0a7c6727c7059e362b9f658 (HEAD -> rawhide, origin/rawhide, origin/HEAD) Author: Lukas Vrabec <lvrabec> Date: Thu Sep 5 09:05:36 2019 +0200 Allow devicekit_var_lib_t dirs to be created by systemd during service startup. BZ(1748997)
*** Bug 1749575 has been marked as a duplicate of this bug. ***
Rawhide 32 Name : upower Version : 0.99.11 Release : 2.fc32 Architecture : x86_64 sudo /usr/libexec/upowerd executed in terminal restores panel icon and screen brightness vertical slider control on mate desktop until reboot. Is dbus/systemd failing to start the upower.service due to root requirement? >>>>>>>>>>>> systemctl status upower.service ● upower.service - Daemon for power management Loaded: loaded (/usr/lib/systemd/system/upower.service; disabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2019-09-10 21:42:50 ADT; 12min ago Docs: man:upowerd(8) Process: 1532 ExecStart=/usr/libexec/upowerd (code=exited, status=217/USER) Main PID: 1532 (code=exited, status=217/USER) CPU: 5ms Sep 10 21:42:50 localhost.localdomain systemd[1]: upower.service: Service RestartSec=100ms expired,> Sep 10 21:42:50 localhost.localdomain systemd[1]: upower.service: Scheduled restart job, restart co> Sep 10 21:42:50 localhost.localdomain systemd[1]: Stopped Daemon for power management. Sep 10 21:42:50 localhost.localdomain systemd[1]: upower.service: Start request repeated too quickl> Sep 10 21:42:50 localhost.localdomain systemd[1]: upower.service: Failed with result 'exit-code'. Sep 10 21:42:50 localhost.localdomain systemd[1]: Failed to start Daemon for power management. >>>>>>> systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION ● upower.service loaded failed failed Daemon for power management LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. 1 loaded units listed.
Addendum This issue has been observed with recent Ubuntu, Debian package updates.
This seems to be happening to F30 now, in openQA update tests on staging, e.g. https://openqa.stg.fedoraproject.org/tests/677283 - the test fails because upower.service didn't start, upower.service failed because of this. However, the F30 package log claims the patch is in it, the line "- Allow devicekit_var_lib_t dirs to be created by systemd during service startup. BZ(1748997)" is present in 3.14.3-46.fc30 changelog and the test VM has -52. So not sure what's going on there.
so yeah, it seems that upower 0.99.11 went stable for F30 about 5 days ago, and 2 days ago the base F30 disk image for openQA update tests on staging instance was rebuilt, so at that point it would have included upower 0.99.11. From then on, this test has failed every time it's run on that disk image. On prod openQA instance the base image was last built just before upower 0.99.11 went stable, so it's still OK, but next time the disk image gets rebuilt we'll have this problem on prod too. upower 0.99.11 went stable for Fedora 31 on 2019-11-18, the F31 disk image was also rebuilt for stg on 2019-11-25, and this test is passing on F31 updates, so it seems we don't have the bug on F31. But somehow on F30, the fix isn't working. Perhaps something changed in selinux-policy itself between F30 and F31 which means the fix for this doesn't backport successfully to F30?
commit 536f614aff5bd7091a2ff3204a8114e8fd126223 (HEAD -> f30, origin/f30) Author: Lukas Vrabec <lvrabec> Date: Mon Aug 5 18:18:03 2019 +0200 Allow systemd to create and bindmount dirs. Add systemd_logind_var_lib_t to attribute systemd_mount_directory. Allow systemd create targets with labels part of systemd_mount_directory Resolves: rhbz#1734831
Can you do a package build and update, Lukas? Thanks!
Yes, sure. Zdenek can do that.
*** Bug 1778886 has been marked as a duplicate of this bug. ***
FEDORA-2019-e9d8868185 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-e9d8868185
selinux-policy-3.14.3-53.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-e9d8868185
Build is in progress.
No longer needs to be marked as an F32 blocker as it's fixed in Rawhide.
container-selinux-2.123.0-2.fc30, selinux-policy-3.14.3-53.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-e9d8868185
container-selinux-2.123.0-2.fc30, selinux-policy-3.14.3-53.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.