Description of problem: New CUPS fails to print to a known good IPP printer in most circumstances Version-Release number of selected component (if applicable): cups-1.2.0-1.1 How reproducible: Always Steps to Reproduce: 1. send a job to printer from any app except: a) test page from system-config-printer, or b) a2ps. I.E. Try to print from acroread, firefox, thunderbird, man -t | lpr, ..., etc. 2. 3. Actual results: Nothing gets printed, cups reports: (/usr/lib/cups/backend/ipp) stopped with status 1 and stops queue Expected results: something prints & cups leaves queue turned on Additional info: After yum upgrade this morning printing stopped working. I am printing using IPP to a Xerox Phaser 8400DP. The failure happens using the PPD file from Xerox's support site, imported into cups. I have been using this PPD and identical configuration of CUPS for over two years, since FC3 and its old version of cups. It also occurs using the CUPS generic PostScript driver, which has also worked in the past. Based on past experience, I removed the printer from my CUPS configuration and restarted the cups service, then, using system-config-printer, imported the Xerox supplied PPD file, and finally added the printer. I have also edited the CUPS config to use generic Postscript driver with the same results. To eliminate as much variation as possible, I've used the results from man -t cupsd.conf | lpr as my failure test case. Directing the output of man -t to a file and then netcat-ing it directly to port 9100 of the printer does print, but this doesn't allow me access to any of the features of the printer. I have turned on debugging in /etc/cupsd.conf and captured both the CUPS logs and network traffic (using ethereal) corresponding to a) successful printing using the command "a2ps .sig.pub" and b) the typical, unsuccessful printing using "man -t cupsd.conf | lpr". I will attach an excerpt from the (not very revealing) /var/log/cups/error_log, and subsequently the mush more revealing packet captures.
Created attachment 129256 [details] excerpt from /var/log/cups/error_log, with LogLevel set to debug
Created attachment 129257 [details] ethereal packet capture of successful printing from a2ps
Created attachment 129258 [details] ethereal packet capture of unsuccessful printing from man -t
Please turn on 'debug2' logging, as follows. Edit /etc/cups/cupsd.conf and change the 'LogLevel' line to read: LogLevel debug2 Then stop cups: /sbin/service cups stop Clear out the error_log: >/var/log/cups/error_log Then start cups again: /sbin/service cups start Try your print job, and when it fails attach the /var/log/cups/error_log file here. Thanks.
Created attachment 129327 [details] debug2 log of failed job
Created attachment 129331 [details] debug2 log of successful job
Methodology: check that queue is up, stop cups, clear error log, start cups, send job, stop cups, send log. man -t cupsd.conf | lpr fails a2ps .sig succeeds. One more data point - printing from OpenOffice.org also fails; still haven't found any further apps that succcessfully print.
Reported upstream: http://cups.org/str.php?L1704
When rebuilt with the additional patch http://cups.org/strfiles/1704/str1704.patch from upstream, cups-1.2.0-1.3.src.rpm from updates-testing no longer exhibits the failures. I'd suggest rolling the upstream patch str1704.patch into a new cups when it moves from updates-testing to updates.
cups-1.2.0-1.4 (shortly to appear in updates-testing) contains this fix. Thanks for helping out.
I'm unable to print from RHEL3 to FC5 printer shared by IPP so not only sending but receiving too has been broken in IPP subsystem. Updating to cups-1.2.0-1.4 solves the problem. I'm voting to move this update from testing to regular updates.
Milan: thanks for confirming the fix. There are a couple more fixes I'd like to get in first.
I have the same problem after update. lpstat -p gives printer epson disabled since Mon 22 May 2006 07:30:41 AM EDT - Unable to open USB device "usb:/dev/usb/lp0": Permission denied
Erik: your problem is different; it uses the usb backend, not the ipp backend. Please file a separate bug report.
Fixed in 1.2.1-1.2.