Description of problem: Since updating to colord*0.1.29-1.fc19.x86_64, colord fails to start. I see this in /var/log/messages: Feb 9 08:18:02 tlondon dbus-daemon[618]: dbus[618]: [system] Activating via systemd: service name='org.freedesktop.ColorManager' unit='colord.service' Feb 9 08:18:02 tlondon dbus[618]: [system] Activating via systemd: service name='org.freedesktop.ColorManager' unit='colord.service' Feb 9 08:18:02 tlondon colord: Using config file /etc/colord.conf Feb 9 08:18:02 tlondon colord: Using mapping database file /var/lib/colord/mapping.db Feb 9 08:18:02 tlondon colord[2205]: (colord:2205): Cd-WARNING **: CdMain: failed to load mapping database: Failed to migrate mappings: SQL error: attempt to write a readonly database Feb 9 08:18:02 tlondon systemd[1]: colord.service: main process exited, code=exited, status=1/FAILURE Feb 9 08:18:02 tlondon systemd[1]: Unit colord.service entered failed state Version-Release number of selected component (if applicable): colord-debuginfo-0.1.29-1.fc19.x86_64 colord-gtk-0.1.24-1.fc19.x86_64 colord-libs-0.1.29-1.fc19.x86_64 colord-0.1.29-1.fc19.x86_64 How reproducible: Every boot, every time. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I've "made this go away" by doing the following: 1. I tried to run 'strace /usr/libexec/colord' from a root shell with SELinux enabled. It failed. 2. I set SELinux to permissive and reran 'strace /usr/libexec/colord'; it succeeded (that is, it initialized, and was left waiting on a MUTEX). 3. I now set SELinux to enforcing mode, and reran 'strace /usr/libexec/colord'; it succeeded. 4. Enforcing reboots now "work": colord starts up. I'm guessing this may possibly be a Rawhide related SELinux issue. I'll contact dwalsh@/mgrepl@ ....
I spotted this on my Fedora 18 system, SELinux was not involved, it was simply a file ownership issue: # ll /var/lib/colord/ total 12 drwxr-xr-x. 2 colord colord 4096 Feb 8 17:11 icc -rw-r--r--. 1 root root 3072 Aug 17 2011 mapping.db -rw-r--r--. 1 root root 4096 May 28 2011 storage.db after changing ownership to those files to colord:colord, colord can now be started via dbus: # ll /var/lib/colord/ total 20 drwxr-xr-x. 2 colord colord 4096 Feb 8 17:11 icc -rw-r--r--. 1 colord colord 5120 Feb 15 09:56 mapping.db -rw-r--r--. 1 colord colord 6144 Feb 15 09:56 storage.db
Interesting. Not on my system, and colord starts on boot. I don't recall the mode for the dir /var/lib/colord, though. [root@tlondon ~]# ls -ld /var/lib/colord drwxr-xr-x. 3 colord colord 4096 Feb 10 11:37 /var/lib/colord [root@tlondon ~]# ls -l /var/lib/colord total 20 drwxr-xr-x. 2 colord colord 4096 Feb 4 14:27 icc -rw-r--r--. 1 root root 5120 Feb 10 11:37 mapping.db -rw-r--r--. 1 root root 6144 Feb 10 11:37 storage.db [root@tlondon ~]# getfacl /var/lib/colord getfacl: Removing leading '/' from absolute path names # file: var/lib/colord # owner: colord # group: colord user::rwx group::r-x other::r-x [root@tlondon ~]# getfacl /var/lib/colord/* getfacl: Removing leading '/' from absolute path names # file: var/lib/colord/icc # owner: colord # group: colord user::rwx group::r-x other::r-x # file: var/lib/colord/mapping.db # owner: root # group: root user::rw- group::r-- other::r-- # file: var/lib/colord/storage.db # owner: root # group: root user::rw- group::r-- other::r-- [root@tlondon ~]# systemctl status colord.service colord.service - Manage, Install and Generate Color Profiles Loaded: loaded (/usr/lib/systemd/system/colord.service; static) Active: active (running) since Fri 2013-02-15 06:21:04 PST; 6min ago Main PID: 649 (colord) CGroup: name=systemd:/system/colord.service └─649 /usr/libexec/colord Feb 15 06:22:16 tlondon.localhost.org colord[649]: device removed: xrandr-Len... Feb 15 06:22:16 tlondon.localhost.org colord[649]: device removed: xrandr-Hew... Feb 15 06:22:20 tlondon.localhost.org colord[649]: Device added: xrandr-Lenov... Feb 15 06:22:20 tlondon.localhost.org colord[649]: Device added: xrandr-Hewle... Feb 15 06:22:20 tlondon.localhost.org colord[649]: Profile added: icc-6d64814... Feb 15 06:22:20 tlondon.localhost.org colord[649]: Automatic metadata add icc... Feb 15 06:22:20 tlondon.localhost.org colord[649]: Profile added: icc-8800a33... Feb 15 06:22:20 tlondon.localhost.org colord[649]: Profile added: icc-bc5dc11... Feb 15 06:22:20 tlondon.localhost.org colord[649]: Automatic metadata add icc... Feb 15 06:22:20 tlondon.localhost.org colord[649]: Profile added: icc-5071fbf... [root@tlondon ~]#
I boot to a text login and then do startx, colord isn't started until later, when a print dialog gets cups automatically started, which in turn starts colord: dbus-daemon[534]: dbus[534]: [system] Activating via systemd: service name='org.freedesktop.ColorManager' unit='colord.service'
*** Bug 847421 has been marked as a duplicate of this bug. ***
I've fixed this in 0.1.30-1, I'll build this for F18 and rawhide now.
colord-0.1.30-1.fc18, colorhug-client-0.1.14-1.fc18, colord-gtk-0.1.24-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/FEDORA-2013-2053/colord-0.1.30-1.fc18,colorhug-client-0.1.14-1.fc18,colord-gtk-0.1.24-1.fc18
Package colord-0.1.30-1.fc18, colorhug-client-0.1.14-1.fc18, colord-gtk-0.1.24-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing colord-0.1.30-1.fc18 colorhug-client-0.1.14-1.fc18 colord-gtk-0.1.24-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-2053/colord-0.1.30-1.fc18,colorhug-client-0.1.14-1.fc18,colord-gtk-0.1.24-1.fc18 then log in and leave karma (feedback).
Comment> build colord-0.1.30-1.fc18 fixes bug I left positive karma at https://admin.fedoraproject.org/updates/F18/FEDORA-2013-2053
colord-0.1.30-1.fc18, colorhug-client-0.1.14-1.fc18, colord-gtk-0.1.24-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.