Bug 131573 - cups-config-daemon refuses to start
Summary: cups-config-daemon refuses to start
Alias: None
Product: Fedora
Classification: Fedora
Component: hal
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: John (J5) Palmieri
QA Contact:
Depends On:
Blocks: FC3Target
TreeView+ depends on / blocked
Reported: 2004-09-02 13:34 UTC by Daniel Malmgren
Modified: 2013-03-13 04:46 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-09-03 17:28:34 UTC

Attachments (Terms of Use)

Description Daniel Malmgren 2004-09-02 13:34:26 UTC
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):

How reproducible:

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:

Comment 1 Daniel Malmgren 2004-09-02 13:40:15 UTC
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.

Comment 2 Tim Waugh 2004-09-02 13:43:03 UTC
Should be 'hal-cups-utils', but there is no bugzilla component for it.

Comment 3 Daniel Malmgren 2004-09-02 13:49:27 UTC
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.

Comment 4 John (J5) Palmieri 2004-09-02 14:34:30 UTC
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.

Comment 5 Daniel Malmgren 2004-09-03 13:24:54 UTC
> 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?

Comment 6 John (J5) Palmieri 2004-09-03 15:46:53 UTC
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.

Comment 7 Daniel Malmgren 2004-09-03 17:28:34 UTC
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...

Note You need to log in before you can comment on or make changes to this bug.