On current Rawhide - even with selinux-policy-40.10-1.fc40 , which should resolve https://bugzilla.redhat.com/show_bug.cgi?id=2259679 - colord-1.4.7-1.fc40 seems to sometimes fail on startup. In the journal I see: [adamw@xps13a tmp]$ journalctl --file var/log/journal/7ba90c716e2c42978f6da33f6b8c90bd/system.journal -u colord Jan 27 13:20:32 fedora systemd[1]: Starting colord.service - Manage, Install and Generate Color Profiles... Jan 27 13:20:32 fedora colord[1064]: CdMain: failed to load mapping database: Can't open database: unable to open database file Jan 27 13:20:32 fedora systemd[1]: colord.service: Main process exited, code=exited, status=1/FAILURE Jan 27 13:20:32 fedora systemd[1]: colord.service: Failed with result 'exit-code'. Jan 27 13:20:32 fedora systemd[1]: Failed to start colord.service - Manage, Install and Generate Color Profiles. Jan 27 13:20:33 fedora systemd[1]: Starting colord.service - Manage, Install and Generate Color Profiles... Jan 27 13:20:33 fedora colord[1145]: CdMain: failed to load mapping database: Can't open database: unable to open database file Jan 27 13:20:33 fedora systemd[1]: colord.service: Main process exited, code=exited, status=1/FAILURE Jan 27 13:20:33 fedora systemd[1]: colord.service: Failed with result 'exit-code'. Jan 27 13:20:33 fedora systemd[1]: Failed to start colord.service - Manage, Install and Generate Color Profiles. there are no AVCs around this in the journal. The only SELinux denial I can find logged anywhere at all is in audit.log, and it's this: type=AVC msg=audit(1706390413.212:349): avc: denied { read write } for pid=2153 comm="plymouthd" name="kmsg" dev="devtmpfs" ino=10 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:kmsg_device_t:s0 tclass=chr_file permissive=0 which has been around for a long time, and is clearly not relevant. This didn't happen when we re-ran the openQA tests on colord itself after the selinux-policy update, but it has now failed three times on https://bodhi.fedoraproject.org/updates/FEDORA-2024-66dfbeb320 , blocking that update from going stable. I've verified in the logs of that update that the versions of colord and selinux-policy present are: selinux-policy-targeted-40.10-1.fc40.noarch colord-1.4.7-1.fc40 and those versions were present when the base disk image on which the test ran was built.
I've done a new build with the missing systemd stuff[1] included. Can you give colord-1.4.7-3.fc40 a go, or will it be included automatically? +ConfigurationDirectory=colord +StateDirectory=colord +CacheDirectory=colord
It went through automatically, but as this was apparently a periodic failure I'll have to keep an eye on other test results to see if it resolved it.
I'm reverting the workaround I put in place for this so we'll know for sure (because tests will start failing if not).
Hasn't failed again today, so let's say this is good, thanks.