Bug 100913
Summary: | Severn/Shrike CUPS interop failure | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux Beta | Reporter: | Need Real Name <kodis> |
Component: | cups | Assignee: | Tim Waugh <twaugh> |
Status: | CLOSED WORKSFORME | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | beta1 | CC: | mitr |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-09-08 16:30:41 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: | |||
Bug Depends On: | |||
Bug Blocks: | 100644 |
Description
Need Real Name
2003-07-27 00:22:05 UTC
For the first part of your report: There is no need to 'set the queue up': CUPS has detected the queue on the remote machine and it is ready to use. The 'Test' menu bar item should be usable, for instance. Browsed queues are immediately usable on the local machine. For the error dialog part: It sometimes takes a while for CUPS to become available after changes are applied. What happens if you try a test page from 'Test' on the menu bar? The remote queue doesn't seem ready to use. While visible, it's unusable. Trying to print a test page from 'Test' on the menu bar results in the same 'Error' dialog box saying that 'There was a problem sending CUPS test page to 'hp' queue: lpr: unable to print file: server-error-service-unavailable'. This error determination was made without any network traffic being sent to the machine hosting the remote printer. Another indication that the remote print queue isn't ready to use is that the 'Set as default' options (both in the 'Action' menu item, and in the mouse button 3 menu) are greyed out. Repeating the test after restarting both CUPS servers, disabling packet filtering on both sides, and waiting for several ipp broadcasts to be received from the machine hosting the remote printer makes no difference. 'Set as default' will be greyed out normally. But you should be able to print a test page. Please set LogLevel to debug2 in /etc/cups/cupsd.conf, restart cups, and try again. Then look in /var/log/cups/error_log for clues. I shut down cupsd on both the shrike machine hosting the locally-attached printer (papa) and on the severn machine from which I was trying to print a test page (scrap). I set Loglevel to 2 in both cupsd.conf files, truncated both error_log files, restarted both cupsd servers, and tried printing two test pages. Both attempts failed as described previously. While I see indications of a failure in the error_log file, it isn't obvious what is causing the failure. The error_log file from the machine where I tried to print the test page is at http://home.comcast.net/~kodis/cups/error_log.scrap I've also made available a copy of the cupsd.conf file as cupsd.conf.scrap, and the error log and configuration files from the machine to which the printer is connected as error_log.papa and cupsd.conf.papa The error_log files don't show any print attempt -- in other words, I don't think that the scheduler on the Severn machine has any knowledge of the print job. Please try: lpstat -s <-- should list available print queues lp -d hp /usr/share/printconf/tests/testpage.asc <-- should try to print file If the 'lp' command fails, please try: strace lp -d hp /usr/share/printconf/tests/testpage.asc 2>log and attach the log file. Thanks. *ping* No feedback. |