Bug 132388 - cups-config-daemon doesn't always notify cupsd to reload when needed
Summary: cups-config-daemon doesn't always notify cupsd to reload when needed
Alias: None
Product: Fedora
Classification: Fedora
Component: hal-cups-utils   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Colin Walters
QA Contact:
Depends On:
Blocks: 134890
TreeView+ depends on / blocked
Reported: 2004-09-12 03:16 UTC by W. Michael Petullo
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-20 02:54:11 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Output from lshal with USB Brother HL-1440 printer attached. (75.36 KB, text/plain)
2004-09-15 02:50 UTC, W. Michael Petullo
no flags Details
Output from lshal with USB Brother HL-1440 printer attached (75.24 KB, text/plain)
2004-10-26 03:50 UTC, W. Michael Petullo
no flags Details
Output of tree /sys (69.14 KB, text/plain)
2004-10-27 13:47 UTC, W. Michael Petullo
no flags Details

Description W. Michael Petullo 2004-09-12 03:16:02 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.7.2)
Gecko/20040809 Epiphany/1.3.8

Description of problem:
When I plug my USB Brother HL1440 into my computer, HAL recognizes it
and tries to configure it.  Applications that use libgnomeprint.* see
the printer as "hl-1440-series-1".  However, trying to print to the
printer results in PostScript commands being printed.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.  Plug USB Brother HL1440 in to computer.

2.  One hal-device-manager and notice that HAL recognizes the device.

3.  Open AbiWord and print a document to the hl-1440-series-1 spool
that hal-cupsutils created.

Actual Results:  PostScript commands are printed:

%%%Creator: Gnome Print Version 2.7.1

Expected Results:  The AbiWord document should print as it is
displayed on the screen.

Additional info:

When I configure the printer by hand using system-config-printer, a
file is placed in /etc/cups/ppd.  When hal configures the printer,
there is nothing placed in /etc/cups/ppd.

The ppd file I get from using system-config-printer contains:

*FoomaticIDs: Brother-HL-1440 hl1250
*FoomaticRIPCommandLine: "gs -q -dBATCH -dPARANOIDSAFER -dNOPAUSE -sDE&&
VICE=hl1250%A%Z -sOutputFile=- -"

Comment 1 John (J5) Palmieri 2004-09-13 15:33:01 UTC
Can you attach the output of lshal.  It looks like the USB device is
outputting hl-1440-series as the model whereas foomatic knows it as
hl-1440.  Funny that the driver dialog didn't popup to ask you to
select a driver.  Can you also do:

rpm -q foomatic
rpm -q desktop-printing
rpm -q hal-cups-utils

and get me the output of those commands?  Also check if eggcups is
running in your session.

Comment 2 W. Michael Petullo 2004-09-14 15:10:42 UTC
I am using foomatic 3.0.1-11 and hal-cups-utils-0.5.2-1.  

I did not have desktop-printing installed, though I have now installed
0.10.2-2.  Should there be a dependency somewhere that brings in
desktop-printing automatically?  Or is it not a prerequisite for

I will send the output of lshal as soon as I have time and access to
the printer again.

Comment 3 John (J5) Palmieri 2004-09-14 15:32:10 UTC
hal-cups-utils is a dependency of desktop-printing.  desktop-printing
is not a dependency of any other component as I understand it.  It is
usualy installed by the Anaconda installer when you choose to install
Gnome.  How exactly did you install Fedora?  Was it an upgrade or did
you install from cd?  If it was an upgrade what version did you
upgrade from and how did you install that? Thanks.

Comment 4 W. Michael Petullo 2004-09-14 16:07:22 UTC
I've been tracking Fedora Rawhide since the PowerPC packages have been
available.  I upgraded to Fedora Rawhide from Yellow Dog Linux.  I am
not a typical user as far as installation goes.

rpm -q --whatrequires desktop-printing does say "no package requires

These are just facts.  I'm not advocating creating an RPM dependency
or avoiding one.  Arguments can be made for both alternatives and
things boil down to Fedora's policy.

Comment 5 John (J5) Palmieri 2004-09-14 17:43:33 UTC
Ok, so the package wasn't pulled in when upgrading from YDL.  It is
really up to the maintainer of the desktop-printing package if he
wants to add it as a dependency to a package.  I'm going to close this
bug now but if you could, could you plug in your printer and get me
the output of lshal.  Just attach it to this bug.  Thanks.

Comment 6 W. Michael Petullo 2004-09-15 02:50:26 UTC
Created attachment 103856 [details]
Output from lshal with USB Brother HL-1440 printer attached.

Comment 7 W. Michael Petullo 2004-09-15 14:32:12 UTC
I am re-opening this bug because it is not yet resolved.  Though I
mentioned that I installed desktop-printing, doing this did not
resolve the issue.  I hope to investigate this more tonight.

Comment 8 John (J5) Palmieri 2004-09-15 15:44:33 UTC
I am reassigning this bug to the desktop-printing maintainer.  Basicly
this is a known bug.  Eggcups (which is installed by desktop-printing)
needs to be started in the session.  This happens fine when installed
from scratch but when upgrading from a previous version which did not
have eggcups in the default session, causes then new default session
to not be picked up if you have already modified your session.  A
solution to make eggcups always start up in the session is being

Comment 9 W. Michael Petullo 2004-09-15 23:13:28 UTC
It looks like eggcups is being started:

[mike@imp ~]$ ps aux | grep eggcups
mike      5064  0.0  3.1 43976 8012 ?        Ssl  18:03   0:00 eggcups
--sm-config-prefix /eggcups-ZD0Y6T/ --sm-client-id
117f000001000109521593400000049420002 --screen 0

But running hal_lpqadmin by hand says:

[root@imp capability.d]# /usr/sbin/hal_lpadmin -p
libhal.c 823 : Error sending msg: No property printer.description on
device with id
libhal.c 823 : Error sending msg: No property printer.serial on device
with id
An error occurred while calling printer_needs_config: Service
"com.redhat.PrintDriverSelection" does not exist

Comment 10 Colin Walters 2004-09-16 15:46:25 UTC
What version of eggcups?

Comment 11 W. Michael Petullo 2004-09-16 16:01:17 UTC
As noted in comment #2, I now have desktop-printing 0.10.2-2 installed:

[mike@imp ~]$ eggcups --version
Gnome eggcups 0.10.2

Comment 12 Colin Walters 2004-09-16 16:07:04 UTC
Hm, I think we discovered that version alongside some paleolithic
dinosaur bones :)

Can you try this?

Comment 13 W. Michael Petullo 2004-09-17 03:54:39 UTC
The eggcups included in desktop-printing-0.12-1 crashes immediately
upon executing.  I should note that I am running Fedora Rawhide on
PowerPC.  The backtrace seems to indicate some type of memory corruption:

[mike@imp ~]$ gdb eggcups
GNU gdb Red Hat Linux (6.1post-1.20040607.28rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
This GDB was configured as "ppc-redhat-linux-gnu"...Using host
libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) run
Starting program: /usr/bin/eggcups
[Thread debugging using libthread_db enabled]
[New Thread 805422240 (LWP 5320)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 805422240 (LWP 5320)]
0x001861c8 in ?? ()
(gdb) ba
#0  0x001861c8 in ?? ()
#1  0x0f07c43c in _gnome_cups_request_init ()
   from /usr/lib/libgnomecups-1.0.so.1
#2  0x0f07c43c in _gnome_cups_request_init ()
   from /usr/lib/libgnomecups-1.0.so.1
#3  0x0f07c43c in _gnome_cups_request_init ()
   from /usr/lib/libgnomecups-1.0.so.1
#4  0x0f07c43c in _gnome_cups_request_init ()
   from /usr/lib/libgnomecups-1.0.so.1
#5  0x0f07c43c in _gnome_cups_request_init ()
   from /usr/lib/libgnomecups-1.0.so.1
#6  0x0f07c43c in _gnome_cups_request_init ()
   from /usr/lib/libgnomecups-1.0.so.1
Previous frame inner to this frame (corrupt stack?)

Comment 14 Colin Walters 2004-09-17 18:56:12 UTC

Can you recompile eggcups without optimzation and with debugging info?

Also do you have any i386 machines?  Can you try on them to see
whether this is really ppc-specific?

Comment 15 W. Michael Petullo 2004-09-17 19:13:41 UTC
I built eggcups without optimization and it did NOT receive a SIGSEGV
signal.  Unfortunately, I don't have an x86 machine to test with. 
Could someone run eggcups through valgrind on x86 to look for memory

I have not yet been able to test the non-segfaulting eggcups fully
because I don't have access to the printer right now.  Hopefully, I
will be able to test this tonight.

Comment 16 Colin Walters 2004-09-17 19:44:55 UTC
We've been running eggcups through valgrind regularly, it is pretty clean.

So if you rebuild it with optimization, you get the problem?

Comment 17 W. Michael Petullo 2004-09-18 02:53:10 UTC
I might have been premature in reporting the eggcups segfault.  I am
unable to reproduce it now.  So eggcups 0.12 seems to execute okay.  

The driver configuration dialog now pops up when I plug my printer in.
 When I select a driver, the following is entered into GConf's

<?xml version="1.0"?>
        <entry name="driver" mtime="1095474706" type="string">
        <entry name="model" mtime="1095474706" type="string">
                <stringvalue>HL-1440 series</stringvalue>
        <entry name="make" mtime="1095474706" type="string">

This all looks reasonable.

However, the end result is still that my printer is not available to
libgnomeprint applications.  The printer is not available in the
application's print dialog.

One thing that strikes me as odd is that /etc/cups/printers.conf is
not updated at all.  Also, nothing for the printer is placed in
/etc/cups/ppd.  /etc/printcap is also empty.

Another issue is that the hotplug event that is associated with the
printer must be triggered while I am logged in.  In other words, if I
log in with the printer already plugged in then I must unplug it and
plug it back it to get the configuration dialog to pop up.

Comment 18 Colin Walters 2004-09-20 16:00:19 UTC
Hmmm.  As for updating printers.conf, it may be that cups makes the
change in memory but doesn't write it out until you restart the daemon.

As for printers not showing up - this is probably because of the
optimization I made recently to have cups broadcast on new printers
instead of polling.  That's only in cups 1:1.1.21-1.rc2.2.  What
version do you have?

Comment 19 John (J5) Palmieri 2004-09-20 16:19:22 UTC
cups should be restarted when the printer is configured.  We need to
handle the case where a user logs onto the desktop with the printer
plugged in.  Note that the dialog should only ever pop up once.  I'm
guessing we can do this with a scan of HAL when the session loads. 
CC'ing davidz on this.  David, how best should we handle this? 
Doesn't g-v-m handle this for drives?

Comment 20 David Zeuthen 2004-09-20 16:32:25 UTC
Yes, when g-v-m starts (along with the session) it mounts all volumes
and when exiting (when the session ends) they are unmounted again. 

You should probably just ask hal for all the printers
(hal_find_device_by_capability) and check thist list against what you
have in gconf.

Comment 21 W. Michael Petullo 2004-09-23 00:32:06 UTC
I still have all of the problems in comment #17 following an update to
the most recent Rawhide.  I deleted the printer entries in ~/.gconf to
cause the entire process to repeat.

Current versions:


There is still nothing in printers.conf after I restart the cups and
cups-config-daemon services.

Comment 22 Colin Walters 2004-09-23 18:57:56 UTC
I just uploaded desktop-printing-0.14, which has John's fixes for this.
Can you give that a try?

Comment 23 John (J5) Palmieri 2004-09-23 19:06:37 UTC
If that doesn't work do me a favor and rerun 

/usr/sbin/hal_lpadmin -p

and post the output.

Comment 24 W. Michael Petullo 2004-09-25 06:18:34 UTC
I just upgraded to the following packages:


Eggcups is now crashing.  The backtrace is worthless because it looks
like the program's stack is corrupt.

Here is the output from /usr/sbin/hal_lpadmin:

[root@imp /]# /usr/sbin/hal_lpadmin -p
libhal.c 869 : Error sending msg: No property printer.description on
device with id
libhal.c 869 : Error sending msg: No property printer.serial on device
with id
An error occurred while calling printer_needs_config: Message did not
receive a reply

Comment 25 W. Michael Petullo 2004-10-03 05:00:13 UTC
I just tried:


Eggcups no longer crashes.  I am once again provided with the driver
selection interface when I plug my printer.  However, my printer is
still not available in applications' print dialog.  Nothing appears in

Comment 26 John (J5) Palmieri 2004-10-04 16:58:00 UTC
Ok, I found the bug and it is fixed in eggcups in CVS.  Basicly the
values put into gconf are the ones reported by hal and not the ones in
the database.  The only reason for the gconf keys is to map the hal
values to the database values.  If we are mapping hal to hal then you
can see why it quickly becomes useless ;-).

I'll note here when the fix is in rawhide.  When the next version
comes out can you update and run "gconftool-2 --recursive-unset
/system/printing" to unset the current values in gconf and then try
plugging your printer in again.

Thanks for for helping to get this resolved.

Comment 27 John (J5) Palmieri 2004-10-04 21:35:18 UTC
This has been updated in rawhide to desktop-printing-0.15.2-2.

Comment 28 W. Michael Petullo 2004-10-06 03:47:42 UTC
The printer is now configured properly when I plug it in while logged
in.  I am prompted to choose a driver and the printer becomes
available in applications that use gnomeprint.  Very nice!

The only remaining issue is that the hotplug event must be generated
while the user is logged on.  See the last paragraph in comment #17. 
Comment #20 talks about one solution for the desktop-printing package  

This is a problem that other Fedora components have.  For issues
related to setting USB scanner permissions, see:


Comment 29 John (J5) Palmieri 2004-10-06 05:41:23 UTC
eggcups will iterate over printers and configure them (if they were
not autoconfigured on hal startup) when the session starts.  As for
USB scanners have you tested it with recent builds?  I don't have a
scanner to test but there are a class of devices that should get
permissions set when a person logs into their session as the console
user.  If this is not the case please file a new bug.

Closing this bug.  Thanks for your help.

Comment 30 W. Michael Petullo 2004-10-21 02:07:10 UTC
As I mentioned in comment #28, this bug was fixed.  However, after
some updates, something is wrong again.


I once again do not get a driver prompt when the printer is plugged
in.  Eggcups is running.  Running hal_lpadmin by hand also does not work:

[mike@imp ~]$ /usr/sbin/hal_lpadmin -p
libhal.c 911 : Error sending msg: No device with id

The printer is listed in the hal tree, though:

[mike@imp ~]$ lshal | grep
lshal version 0.4.0
udi = '/org/freedesktop/Hal/devices/usb_device_4f9_d_100_-1_noserial-0'
  info.udi =
'/org/freedesktop/Hal/devices/usb_device_4f9_d_100_-1_noserial-0' (string)
  info.parent =
'/org/freedesktop/Hal/devices/usb_device_4f9_d_100_-1_noserial'  (string)
udi = '/org/freedesktop/Hal/devices/usb_device_4f9_d_100_-1_noserial'
  info.udi =
'/org/freedesktop/Hal/devices/usb_device_4f9_d_100_-1_noserial'  (string)

Comment 31 John (J5) Palmieri 2004-10-21 19:18:12 UTC
please upgrade to hal-cups-utils 0.5.2-7 and try again.  

Comment 32 John (J5) Palmieri 2004-10-21 19:45:52 UTC
Hmm, looks like 0.5.2-7 was not built into fc3.  I'm building it into
head right now and it may take time to propigate.

Comment 33 John (J5) Palmieri 2004-10-21 20:09:26 UTC
You can get packages to test at:

Comment 34 W. Michael Petullo 2004-10-25 02:16:14 UTC


I still have no luck.  If I plug my printer in and watch things with
top, I can see usb.agent, princonf-tui, foomatic-config and
foomatic-combo-xml execute.  However, I am not prompted for a driver
and the printer does not get configured.

I thought it was strange that printconf-tui runs instead of printconf-gui.

Running hal_lpadmin by hand says:

# hal_lpadmin -p
libhal.c 911 : Error sending msg: No property info.capabilities on
device with id

Comment 35 John (J5) Palmieri 2004-10-25 14:16:05 UTC
printconf-tui has the automation code that is run as root.  The dialog
is a seperate userspace process.  The URI you are using looks wrong. 
That looks like the parent of the device.  It should be:


Also run gconf-editor as your user and check the /system/printing keys.  

if there is anything in there please run:

gconftool-2 --recursive-unset /system/printing

Now unplug your printer and plug it back in.  You should get the dialog.

Comment 36 W. Michael Petullo 2004-10-26 03:50:42 UTC
Created attachment 105768 [details]
Output from lshal with USB Brother HL-1440 printer attached

Still no dialog.  See comment #34.  I see all kinds of printer configuration
processes listed by top but no dialog.	Yes, I am clearing out gconf's

Comment 37 John (J5) Palmieri 2004-10-26 15:02:37 UTC
Ah, for some reason your new lshal output is not detecting your
printer as having the capabilities of a printer (the old one did).  We
detect this using the /sys directory.  can you install the "tree"
program and attach the output of this command:

tree /sys

It looks like it might be a kernel problem.

Comment 38 W. Michael Petullo 2004-10-27 13:47:49 UTC
Created attachment 105838 [details]
Output of tree /sys

Uh oh.	I use a custom-built kernel.  I have not changed my kernel config since
this worked, but I have moved on to a new version.  A quick look at Red Hat's
kernel patches did not reveal any USB printer-specific patches, though.

Comment 39 John (J5) Palmieri 2004-10-27 15:48:55 UTC
Did you load the usblp module?  Can you try booting a stock kernel and
see if the problem is fixed?  If that is the case we can at least
narrow it down to the kernel. 

Comment 40 W. Michael Petullo 2004-10-30 02:55:35 UTC
This does NOT seem to be kernel related.  

I pulled in an update on Thursday that gets almost fixes this (NO
kernel changes).  I once again was prompted for a driver when I
plugged in my printer.  Selecting the proper driver updated
/etc/cups/printers.conf and /etc/cups/ppd/hl-1440-series-1.ppd. 
HOWEVER, I had to manually re-start cups in order to get applications
to notice the newly configured printer.

So we are almost back to the good state we were in at comment #28.

I don't know what package update fixed this.  Here is a list of the
packages updated since comment #34:

Oct 27 11:17:56 Installed: net-snmp-libs.ppc 5.1.2-11
Oct 27 11:18:03 Installed: net-snmp.ppc 5.1.2-11
Oct 27 11:18:40 Installed: ethereal.ppc 0.10.6-3
Oct 27 11:43:43 Installed: ethereal-gnome.ppc 0.10.6-3
Oct 28 11:35:50 Updated: libxml2.ppc 2.6.14-2
Oct 28 11:35:52 Updated: libgcc.ppc 3.4.2-6.fc3
Oct 28 11:36:30 Updated: python.ppc 2.3.4-11
Oct 28 11:36:51 Updated: hal.ppc 0.4.0-9
Oct 28 11:37:14 Updated: libgcj.ppc 3.4.2-6.fc3
Oct 28 11:37:16 Updated: libstdc++.ppc 3.4.2-6.fc3
Oct 28 11:37:18 Updated: cups-libs.ppc 1:1.1.22-0.rc1.8
Oct 28 11:37:21 Updated: libstdc++-devel.ppc 3.4.2-6.fc3
Oct 28 11:38:11 Updated: libgcj-devel.ppc 3.4.2-6.fc3
Oct 28 11:38:15 Updated: NetworkManager.ppc 0.3.1-2
Oct 28 11:38:23 Updated: initscripts.ppc 7.93.2-1
Oct 28 11:38:46 Updated: libgal2.ppc 2:2.2.3-3
Oct 28 11:38:49 Updated: cpp.ppc 3.4.2-6.fc3
Oct 28 11:38:58 Updated: gcc.ppc 3.4.2-6.fc3
Oct 28 11:39:03 Updated: lvm2.ppc 2.00.25-1.01
Oct 28 11:39:07 Updated: gcc-java.ppc 3.4.2-6.fc3
Oct 28 11:39:11 Updated: libxml2-python.ppc 2.6.14-2
Oct 28 11:39:24 Updated: python-devel.ppc 2.3.4-11
Oct 28 11:39:29 Updated: redhat-menus.noarch 1.13-1
Oct 28 11:39:48 Updated: cups.ppc 1:1.1.22-0.rc1.8
Oct 28 11:39:52 Updated: gcc-c++.ppc 3.4.2-6.fc3
Oct 28 11:39:55 Updated: hal-gnome.ppc 0.4.0-9
Oct 28 11:39:57 Updated: NetworkManager-gnome.ppc 0.3.1-2
Oct 28 11:40:08 Updated: libxml2-devel.ppc 2.6.14-2
Oct 28 11:40:10 Updated: hal-devel.ppc 0.4.0-9
Oct 28 11:40:12 Updated: cups-devel.ppc 1:1.1.22-0.rc1.8
Oct 28 11:40:15 Updated: fedora-logos.noarch 1.1.29-1

Comment 41 John (J5) Palmieri 2004-10-30 16:53:21 UTC
Do you have SE-Linux turned on?

Comment 42 W. Michael Petullo 2004-10-30 19:12:23 UTC
SELinux is not enforcing its policy.  I have turned it off
semi-permanently as I work on bugs like this one.

Comment 43 Colin Walters 2004-10-30 19:19:16 UTC
I seriously doubt SELinux has anything to do with this, as none of the
daemons and programs in the code path (dbus, cups, user session) are
currently restricted by the targeted policy.

Do you see avc denials in /var/log/messages?  If not, it's
overwhelmingly likely the bug is elsewhere.  If you want to turn it
off temporarily, please use "setenforce 0".

Comment 44 John (J5) Palmieri 2004-10-30 19:42:23 UTC
Ok, the only other thing I can think of is the program you are using
does not listen to cups updates and only gets a list of printers when
it is started.  Have you tried plugging in the printer and then
starting the program?  Keep in mind it can take upwards of 30 seconds
for the configuration to catch (the app I use to test is gedit).  I'm
wondering if the codepath has some oddities on ppc also.  That is most
unlikely though.  Perhaps you can stop the cups-config-daemon and run
it by hand using --daemon=no and post that output.   Thanks for
helping test the code.

Comment 45 W. Michael Petullo 2004-10-31 04:06:34 UTC
As I mentioned above, SELinux is not enforcing my policy.  I'm pretty
familiar with SELinux and I have it off for the purpose of performing
tests like these.

Here is some more information:

1.  Remove all references to the printer from configurations using

2.  gconftool-2 --recursive-unset /system/printing

3.  Plug in printer.

4.  I get prompted for a driver.

5.  Cups config is updated (/etc/cups/printers.conf,
/etc/cups/ppd/hl-1440-series-1.ppd, etc).  I visually confirm that
these configurations are correct at this point.

6.  I watch top until all of the configurations processes are done. 
Cups-config-daemon says:

[root@imp /]# cups-config-daemon --daemon=no
Now run printconf-backend (or restart lpd service).

7.  At this point I do NOT see the printer listed in abiword or
gnumeric's print dialogs.

8.  lpq says, "lpq: error - no default destination available."

9.  Restart cups with /etc/init.d/cups restart.

10. lpq now says, "hl-1440-series-1 is ready, no entries."

11. Printer shows up in abiword and gnumeric's interfaces.

Comment 46 John (J5) Palmieri 2004-11-01 22:14:57 UTC
Can you try again but instead of killing cupsd can you do a kill
-SIGHUP <cupsd's pid>.  That is what should be happening in
cups-config-daemon.  If that doesn't update your printer list then the
problem is in cupsd on ppc.

Comment 47 W. Michael Petullo 2004-11-05 05:00:10 UTC
Manually executing "kill -SIGHUP <cupsd's pid>" DOES get the printer
to show up.

Comment 48 David Anderson 2005-08-10 15:30:33 UTC
I have the same basic problem; I have an HP 2550Ln which I've connected via  
USB. I can see that /etc/cups/cupsd.conf has been updated, but I don't get  
access to the printer until I do "service cups reload".  
I'm using Fedora Core 4, with KDE, and all updates. SELinux is disabled. I 
don't have eggcups running (should I?). 

Comment 49 David Anderson 2005-08-10 15:32:02 UTC
P.S. No kind of alerts or questions or notifications pop up on my desktop at 
all (should they?) 

Comment 50 W. Michael Petullo 2006-03-20 02:54:11 UTC
I have not had a problem with this lately.  I will reopen this bug if it is
encountered again.

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