Bug 481481
| Summary: | LPR no longer knows system default printer, but not LPQ, after upgrading to cups-1.3.7 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Mark London <mrl> |
| Component: | cups | Assignee: | Tim Waugh <twaugh> |
| Status: | CLOSED ERRATA | QA Contact: | desktop-bugs <desktop-bugs> |
| Severity: | high | Docs Contact: | |
| Priority: | low | ||
| Version: | 5.3 | CC: | nyh, pknirsch |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-09-02 11:25:54 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Mark London
2009-01-25 14:16:24 UTC
What does 'lpstat -s' say? 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 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 </Printer> <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 </Printer> etc. What does 'lpstat -s' say on the machine you're seeing the problem with 'lpr' on? 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 Do you have a /root/.cups/lpoptions file? What does it say? 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 This change in behaviour is due to the implementation of cupsGetNamedDest(). Investigation continues. cupsGetNamedDest() does not verify the default printer specified in environment variables or lpoptions files, whereas cupsGetDests2() does. Patch filed upstream. 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. http://rhn.redhat.com/errata/RHBA-2009-1360.html 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. 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. Created a separate report for the remaining issue: bug 565569 |