Bug 131573 - cups-config-daemon refuses to start
cups-config-daemon refuses to start
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: John (J5) Palmieri
:
Depends On:
Blocks: FC3Target
  Show dependency treegraph
 
Reported: 2004-09-02 09:34 EDT by Daniel Malmgren
Modified: 2013-03-13 00:46 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-03 13:28:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Daniel Malmgren 2004-09-02 09:34:26 EDT
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:
Comment 1 Daniel Malmgren 2004-09-02 09:40:15 EDT
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 09:43:03 EDT
Should be 'hal-cups-utils', but there is no bugzilla component for it.
Comment 3 Daniel Malmgren 2004-09-02 09:49:27 EDT
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 10:34:30 EDT
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 09:24:54 EDT
> 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 11:46:53 EDT
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 13:28:34 EDT
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.