Bug 481481 - LPR no longer knows system default printer, but not LPQ, after upgrading to cups-1.3.7
LPR no longer knows system default printer, but not LPQ, after upgrading to c...
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: cups (Show other bugs)
All Linux
low Severity high
: rc
: ---
Assigned To: Tim Waugh
Depends On:
  Show dependency treegraph
Reported: 2009-01-25 09:16 EST by Mark London
Modified: 2010-02-15 11:40 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-02 07:25:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
CUPS Bugs and Features 3082 None None None Never

  None (edit)
Description Mark London 2009-01-25 09:16:24 EST
User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)

After upgrading from cups-1.2.4-11.18.el5 to 1.3.7-8.el5, the lpr command does not know the system default printer:

# lpr
lpr: Error - no default destination available.

However, the lpq command does know the default printer.

# lpq
P54 is not ready
no entries

Resetting the default printer to a different printer and rebooting does not help.  Falling back to the previous version of cups fixes the problem.  My entry in printers.conf looks like this:

<DefaultPrinter P54>
Info Created by redhat-config-printer 0.6.x
DeviceURI lpd://p54.psfc.mit.edu/p54
State Stopped
StateMessage /usr/lib/cups/backend/lpd failed
StateTime 1232831030
Accepting Yes
Shared Yes
JobSheets standard none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer

Reproducible: Always

Steps to Reproduce:
1. Upgrade from cups-1.2.4-11.18.el5 to 1.3.7-8.el5
Actual Results:  
Type the lpr command.

Expected Results:  
The lpr command should know the default printer as specified in /etc/cups/printers.conf

It produces the error message:

lpr: Error - no default destination available.
Comment 1 Tim Waugh 2009-01-25 10:10:08 EST
What does 'lpstat -s' say?
Comment 2 Mark London 2009-01-25 10:18:56 EST
It says the following (both before and after the upgrade):

system default destination: p114
device for P103: socket://p103:9100
device for p114: socket://p114.psfc.mit.edu:9100
device for p55: socket://p55.psfc.mit.edu:9100
device for p82: socket://p82.psfc.mit.edu:9100
device for p87: lpd://p87.psfc.mit.edu
device for p88: lpd://p88.psfc.mit.edu
device for p96: lpd://p96.psfc.mit.edu/p96
device for p97: lpd://p97.psfc.mit.edu
device for p98: lpd://p98.psfc.mit.edu
Comment 3 Mark London 2009-01-25 14:44:09 EST
FWIW, a minor correction, I just realized I issued the lpstat command on a different computer than the one from which the printers.conf came from that I had posted earlier,  although both had the new cups installed on them.  The printer.conf where I issued the lpstat command on, looks like:

# Printer configuration file for CUPS v1.1.22rc1
# Written by cupsd on Wed 07 May 2008 08:38:54 PM EDT
<Printer P103>
Info Xereox Phaser 8550dp
Location NW21-2
DeviceURI socket://p103:9100
State Idle
Accepting Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
<DefaultPrinter p114>
Info Xerox Phaser 8550DT
Location NW21-187
DeviceURI socket://p114.psfc.mit.edu:9100
State Idle
Accepting Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0

Comment 4 Tim Waugh 2009-01-26 05:05:35 EST
What does 'lpstat -s' say on the machine you're seeing the problem with 'lpr' on?
Comment 5 Mark London 2009-01-26 07:30:51 EST
I'm seeing the lpr problem on ALL the computers that have upgraded to cups.  So the lpstat -s output which I posted earlier is from a machine that I'm seeing the problem on.  They all show a default printer existing.  Here's another example:

# lpq
P54 is not ready
no entries
# lpr
lpr: Error - no default destination available

# lpstat -s
system default destination: P54
device for P45: lpd://P45.PSFC.MIT.EDU/P45
device for P46: lpd://PSFC.MIT.EDU/P46
device for P54: lpd://p54.psfc.mit.edu/p54
device for P55: lpd://P55.PSFC.MIT.EDU/P55
device for P63: lpd://P63.PSFC.MIT.EDU/P63
device for P65: lpd://P65.PSFC.MIT.EDU/P65
device for P70: lpd://P70.PSFC.MIT.EDU/P70
device for P73: lpd://p73.psfc.mit.edu/p73
device for P75: lpd://p75.psfc.mit.edu/p75
device for p82: lpd://p82.psfc.mit.edu/p82
device for P84: lpd://p84.psfc.mit.edu/p84
device for P85: lpd://p85.psfc.mit.edu/P85
device for P87: lpd://p87.psfc.mit.edu/P87
Comment 6 Tim Waugh 2009-01-29 08:01:57 EST
Do you have a /root/.cups/lpoptions file?  What does it say?
Comment 7 Mark London 2009-01-29 10:10:25 EST
I have no such file.  However, I do have a file called /etc/cups/lpoptions   I deleted this file, and this has fixed my problem. - Mark
Comment 8 Tim Waugh 2009-01-29 12:26:52 EST
This change in behaviour is due to the implementation of cupsGetNamedDest().

Investigation continues.
Comment 9 Tim Waugh 2009-01-30 07:41:11 EST
cupsGetNamedDest() does not verify the default printer specified in environment variables or lpoptions files, whereas cupsGetDests2() does.  Patch filed upstream.
Comment 14 errata-xmlrpc 2009-09-02 07:25:54 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

Comment 15 Nadav Har'El 2010-02-14 06:47:58 EST
Was this bug really fixed in newever versions of CUPS? because it doesn't look this way.

I still see on cups-1.4.2-20.fc12.x86_64, exactly the same problem described in this bug report: lpq knows the default printer, but lpr doesn't:

$ lpr file
lpr: Error - no default destination available.
$ lpq
p2 is ready
no entries

It turns out that the culprit was a .lpoptions file in my home directory (not ~/.cups/lpoptions as someone mentioned above). As soon as I removed this file, everything went back to normal.

Anyway, I think it is a bug to have a situation where lpq chooses one printer, and lpr chooses a different one. They should have either both chosen the broken printer from my ~/.lpoptions, or both chosen the system default printer - it doesn't make sense for one to choose one printer, and the other choose a different printer. Moreover, if my ~/.lpoptions chooses a non-existant printer, it would have been nice to see an error to that effect, not "no default destination available".

I'll file a bug report also upstream.
Comment 16 Nadav Har'El 2010-02-15 11:31:24 EST
I reported this upstream - http://www.cups.org/str.php?L3503 - and according to them this bug does *not* happen in the upstream version. So it is apparently a Redhat-specific bug. I'll report it in a separate bug.
Comment 17 Nadav Har'El 2010-02-15 11:40:02 EST
Created a separate report for the remaining issue: bug 565569

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