Bug 970619 - cups doesn't show any printers after update from 1.5 to 1.6
Summary: cups doesn't show any printers after update from 1.5 to 1.6
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: cups
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-04 13:12 UTC by Jiri Moskovcak
Modified: 2015-02-17 15:27 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-02-17 15:27:32 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Jiri Moskovcak 2013-06-04 13:12:12 UTC
Description of problem:
After updating from F18 to F19 new cups fails to show the printers available on our network. 

Version-Release number of selected component (if applicable):
cups-1.6.2-7.fc19.x86_64

How reproducible:
100%

Steps to Reproduce:
1. install F18
2. setup cups to browse network printers
3. update to F19

Actual results:
no printers in the print dialog (tried evince & firefox)

Expected results:
automatically migrated settings from old cups

Additional info:
I noticed, that this line has been migrated from cupsd.conf, but it doesn't seem to have any effect
# Settings automatically moved from cupsd.conf by RPM package:
BrowsePoll <our network>

Comment 1 Jiri Popelka 2013-06-04 14:07:00 UTC
(In reply to Jiri Moskovcak from comment #0)
> # Settings automatically moved from cupsd.conf by RPM package:
> BrowsePoll <our network>

That's from cups-browsed.conf, right ?
There should also be a note that you need to start&enable cups-browsed service, isn't it there ?

Well, yes, it could be perceived as some sort of regression and we already discussed it:
<jpopelka> I've been thinking about enabling cups-browsed during install if BrowsePoll was moved from cupsd.conf to cups-browsed.conf. Not sure whether we need a FESCo approval (https://fedoraproject.org/wiki/Starting_services_by_default) for this or something similar.
<twaugh> Oh, good point
<twaugh> Another thing that I thought yesterday was: we do want to try to get people to migrate to using mDNS
<twaugh> So we could migrate the settings but maybe not enable the service by default, maybe?
<twaugh> That way it's easy to enable it, but it's also easy to get mDNS working (if it's going to work)
<jpopelka> not sure I understand. mDNS == Avahi support in cups ? service == cups-browsed ? If cups-browsed is running the mDNS doesn't work ?
<twaugh> mDNS == Avahi support in cups
<twaugh> service == cups-browsed
<twaugh> If cups-browsed is running, won't that conflict with CUPS's native mDNS browsing?
<twaugh> e.g. remote BrowsePolled server might be advertising queues with mDNS. Don't want duplicates.

Comment 2 Jiri Moskovcak 2013-06-05 08:39:18 UTC
(In reply to Jiri Popelka from comment #1)
> (In reply to Jiri Moskovcak from comment #0)
> > # Settings automatically moved from cupsd.conf by RPM package:
> > BrowsePoll <our network>
> 

- yes

> That's from cups-browsed.conf, right ?
> There should also be a note that you need to start&enable cups-browsed
> service, isn't it there ?

- great, that helped
- but still I find it very inconvenient and not user friendly, that service should be started by default

Comment 4 Tim Waugh 2013-06-05 14:23:26 UTC
After further investigation I can see that gtk3 has had the ability to use DNS-SD to discover network CUPS queues since 3.7.12 (in March).  This works in e.g. gedit and Evince, but does not work in Firefox because it uses gtk2 rather than gtk3.

To adjust the CUPS server so that it advertises queues using DNS-SD, make sure "dnssd" is in the BrowseLocalProtocols list in /etc/cups/cupsd.conf, like this:

BrowseLocalProtocols CUPS dnssd

(this is the default)

Comment 6 Jiri Moskovcak 2013-06-07 08:33:37 UTC
(In reply to Tim Waugh from comment #4)
> After further investigation I can see that gtk3 has had the ability to use
> DNS-SD to discover network CUPS queues since 3.7.12 (in March).  This works
> in e.g. gedit and Evince, but does not work in Firefox because it uses gtk2
> rather than gtk3.
> 
> To adjust the CUPS server so that it advertises queues using DNS-SD, make
> sure "dnssd" is in the BrowseLocalProtocols list in /etc/cups/cupsd.conf,
> like this:
> 
> BrowseLocalProtocols CUPS dnssd
> 
> (this is the default)

That doesn't work for me even though it seems it's set properly:

grep "BrowseLocal" /etc/cups/cupsd.conf 
BrowseLocalProtocols CUPS dnssd

gtk3-3.8.2-1.fc19.x86_64

service cups status
Redirecting to /bin/systemctl status  cups.service
cups.service - CUPS Printing Service
   Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled)
   Active: active (running) since Fri 2013-06-07 08:45:14 CEST; 1h 45min ago
 Main PID: 2205 (cupsd)

And there are no printers in Evince, but they appear when I start cups-browsed.

Comment 7 Tim Waugh 2013-06-07 10:11:34 UTC
Perhaps you don't have the avahi daemon running, or the mDNS communications are blocked by the firewall?

Comment 8 Jiri Popelka 2013-06-07 10:23:19 UTC
Or cups server (running RHEL-6 I guess) in our (mine and reporters) network does not advertise printers via DNS-SD.

Comment 11 Tim Waugh 2013-06-07 11:58:05 UTC
(In reply to Tim Waugh from comment #4)
> After further investigation I can see that gtk3 has had the ability to use
> DNS-SD to discover network CUPS queues since 3.7.12 (in March).  This works
> in e.g. gedit and Evince, but does not work in Firefox because it uses gtk2
> rather than gtk3.
> 
> To adjust the CUPS server so that it advertises queues using DNS-SD, make
> sure "dnssd" is in the BrowseLocalProtocols list in /etc/cups/cupsd.conf,
> like this:
> 
> BrowseLocalProtocols CUPS dnssd
> 
> (this is the default)

To be clear, I'm talking about making this BrowseLocalProtocols change on the CUPS *server*, not the cupsd scheduler instance running on the local machine.

If the CUPS server is only advertising queues using CUPS Browsing, the Fedora 19 clients will need to use cups-browsed from the cups-filters package.

Comment 12 Harish Pillay 2013-07-03 07:55:07 UTC
> To be clear, I'm talking about making this BrowseLocalProtocols change on
> the CUPS *server*, not the cupsd scheduler instance running on the local
> machine.
> 
> If the CUPS server is only advertising queues using CUPS Browsing, the
> Fedora 19 clients will need to use cups-browsed from the cups-filters
> package.

Invoking cups-browsed as root has things working, but I think a systemd script is missing in F19 to startup the cups-browsed.service. Or am I off track here?

Comment 13 Honza Horak 2013-07-03 08:01:11 UTC
(In reply to Harish Pillay from comment #12)
> Invoking cups-browsed as root has things working, but I think a systemd
> script is missing in F19 to startup the cups-browsed.service. Or am I off
> track here?

It's not missing on my F19 system:

# systemctl status cups-browsed
cups-browsed.service - Make remote CUPS printers available locally
   Loaded: loaded (/usr/lib/systemd/system/cups-browsed.service; enabled)
   Active: active (running) since Wed 2013-06-12 14:57:49 CEST; 2 weeks 6 days ago
 Main PID: 628 (cups-browsed)
   CGroup: name=systemd:/system/cups-browsed.service
           └─628 /usr/sbin/cups-browsed

# rpm -qf /usr/lib/systemd/system/cups-browsed.service
cups-filters-1.0.34-1.fc19.x86_64

Comment 14 Harish Pillay 2013-07-03 08:04:33 UTC
(In reply to Honza Horak from comment #13)
> (In reply to Harish Pillay from comment #12)
> > Invoking cups-browsed as root has things working, but I think a systemd
> > script is missing in F19 to startup the cups-browsed.service. Or am I off
> > track here?
> 
> It's not missing on my F19 system:
> 
> # systemctl status cups-browsed
> cups-browsed.service - Make remote CUPS printers available locally
>    Loaded: loaded (/usr/lib/systemd/system/cups-browsed.service; enabled)
>    Active: active (running) since Wed 2013-06-12 14:57:49 CEST; 2 weeks 6
> days ago
>  Main PID: 628 (cups-browsed)
>    CGroup: name=systemd:/system/cups-browsed.service
>            └─628 /usr/sbin/cups-browsed
> 
> # rpm -qf /usr/lib/systemd/system/cups-browsed.service
> cups-filters-1.0.34-1.fc19.x86_64

Indeed you are right.  I've just checked and yes, the service is there
but it was dead. Restarted it and looks like all's well.

Comment 15 Jiri Popelka 2013-07-03 08:09:50 UTC
It was dead because it's not enabled by default (for reason see comment #1).
'systemctl enable cups-browsed.service' should do the trick.

Comment 16 Harish Pillay 2013-07-03 08:18:35 UTC
(In reply to Jiri Popelka from comment #15)
> It was dead because it's not enabled by default (for reason see comment #1).
> 'systemctl enable cups-browsed.service' should do the trick.

yep. did that. thanks.

Comment 17 Richard Shaw 2013-09-18 13:09:01 UTC
I don't think this is my problem but I want to confirm.

I had F18->F18 printer discovery working. When I upgraded (via fedup) my desktop to F19 (which is the "print server") my wife's F18 laptop can no longer discover the printer. I have disabled the firewall on both ends to no avail. I copied cupsd.conf.rpmnew over my config (which seems to drop CUPS browsing) but that didn't fix things either. 

Do I need the cups-browsed service?

Comment 18 Harish Pillay 2013-09-18 13:13:18 UTC
(In reply to Richard Shaw from comment #17)
> I don't think this is my problem but I want to confirm.
> 
> I had F18->F18 printer discovery working. When I upgraded (via fedup) my
> desktop to F19 (which is the "print server") my wife's F18 laptop can no
> longer discover the printer. I have disabled the firewall on both ends to no
> avail. I copied cupsd.conf.rpmnew over my config (which seems to drop CUPS
> browsing) but that didn't fix things either. 
> 
> Do I need the cups-browsed service?

Yes, you need the cups-browsed service.  See #15 and #16 above.

Harish

Comment 19 Brian J. Murrell 2014-05-26 00:07:50 UTC
But really.  Given the prevalence of non-GTK3 applications out there still (hello Libre Office, Chrome, Firefox, etc.), who(!) isn't going to want cups-browsed enabled?

Comment 20 Fedora End Of Life 2015-01-09 18:19:38 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 21 Brian J. Murrell 2015-01-10 15:04:59 UTC
I don't see any activity here that suggests that this has changed even as of F21 so can we please have the Version: field updated to F21?

Comment 22 Tim Waugh 2015-01-12 10:32:55 UTC
This is not anything to do with non-GTK3 applications. Applications having trouble printing need to be migrated to the new discovery method.

Applications using libcups for discovery will already work fine. It's only the applications using their own special discovery mechanisms that need work.

Comment 24 Fedora End Of Life 2015-02-17 15:27:32 UTC
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


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