Description of problem: I can't print anymore, and it seems like the problem is cups-config-daemon not starting. Version-Release number of selected component (if applicable): cups-1.1.21-1.rc2.1 How reproducible: 100% Steps to Reproduce: 1. Try to start the cups-config-daemon service Actual results: In /var/log/messages I sometimes get: Sep 2 15:29:13 Datorn cups-config-daemon: ** ERROR **: Could not acquire service com.redhat.CupsDriverConfig. dbus_bus_acquire_service() says: 'Disconnected prior to receiving a reply' and sometimes I get: Sep 2 15:23:34 Datorn cups-config-daemon: ** ERROR **: Could not acquire service com.redhat.CupsDriverConfig. dbus_bus_acquire_service() says: 'Connection ":1.24" is not allowed to own the service "p,\u000c\u0008\u001b" due to security policies in the configuration file' Expected results: I expect the daemon to start... Additional info:
Fixed this one by changing some "deny" to "allow" in /etc/dbus-1/system.d/cups-config-daemon-dbus.conf. Guess something is wrong here by default.
Should be 'hal-cups-utils', but there is no bugzilla component for it.
Oh, so it's hal related. Wouldn't have been my first guess. I might note then that I'm running latest (0.2.97.cvs20040901-1) version of hal as well.
This should not have any bearing on printing. It only configure cups when we can't auto-detect the printer and only on the first time it asks you to pick a driver. Every other time it will get your configuration from gconf. Since it does not have to wait fo a user to reply the daemon is not needed. So in other words the daemon is just used for first time configuration of printer models that are unknown to us.
> This should not have any bearing on printing. No, I find out there were other reasons why my printing didn't work. btw, does this mean that this daemon only needs to be started when installing new printers?
Since printers can be installed at any time (simply plug in a USB printer) we can't know when to start it so it needs to run. Eventually it will become a system policy daemon which will handle a number of similar session to system requests and only load modules when their signals come in over D-BUS. Fell free to have the service not load if you wish. It just means that for any new printer that our database can not configure you will have to plug it in, configure it, unplug it and plug it back in again. I would like to know why your service wasn't starting up though. Every machine I have tested on the policy rules have worked. Are you at the latest rawhide version? If not can you get the latest version of hal-cups-utils and then do (as root): service cups-config-daemon stop cups-config-daemon --daemon=no and tell me if you still get the same problem.
I'm sorry, but I can't seem to reproduce it today. Don't know if it's today's update or what, but a simple "service cups-config-daemon start" works perfectly today. Guess I'll just mark it as WORKSFORME...