Created attachment 927987 [details] cups log file Description of problem: When trying to print a document on a remote printer, cups submits the job endlessly. E.g. remote site (RHEL6, cups-1.4.2-52.el6_5.2) shows | 192.168.3.24 - - [18/Aug/2014:18:16:11 +0200] "POST /printers/bosch HTTP/1.1" 200 462 Validate-Job successful-ok | 192.168.3.24 - - [18/Aug/2014:18:16:11 +0200] "POST /printers/bosch HTTP/1.1" 200 432 Create-Job successful-ok | 192.168.3.24 - - [18/Aug/2014:18:16:11 +0200] "POST /printers/bosch HTTP/1.1" 200 284 Send-Document successful-ok | 192.168.3.24 - - [18/Aug/2014:18:16:12 +0200] "POST /printers/bosch HTTP/1.1" 200 604 Validate-Job successful-ok | 192.168.3.24 - - [18/Aug/2014:18:16:12 +0200] "POST /printers/bosch HTTP/1.1" 200 574 Create-Job successful-ok | 192.168.3.24 - - [18/Aug/2014:18:16:12 +0200] "POST /printers/bosch HTTP/1.1" 200 284 Send-Document successful-ok triple of messages until 'lprm' has been executed on local machine. I am not sure whether related, but the attached, local logfile shows a 'toner-low-warning'. $ lpq bosch is ready and printing Rank Owner Job File(s) Total Size active ensc 763 (stdin) 1024 bytes $ lpq -P bosch -h louvre bosch is ready and printing Rank Owner Job File(s) Total Size active ensc 5161 (stdin) 1024 bytes 1st ensc 5162 (stdin) 1024 bytes 2nd ensc 5163 (stdin) 1024 bytes 3rd ensc 5164 (stdin) 1024 bytes 4th ensc 5165 (stdin) 1024 bytes 5th ensc 5166 (stdin) 1024 bytes Version-Release number of selected component (if applicable): cups-1.7.4-3.fc20.x86_64 How reproducible: 100% Steps to Reproduce: 1. echo abc | lpr
Has it perhaps started with some recent update ? If so, can you try some older builds https://koji.fedoraproject.org/koji/packageinfo?packageID=54 and let us know which build causes it ? Thanks.
Another approach to diagnosing this would be to watch the IPP traffic between the client and the server, by running this command on either one: tcpdump -s0 -U -w ipp.pcap tcp port ipp Please start the command before submitting the job, and once it has printed more than once, stop the command. Finally, attach ipp.pcap to this bug report using the 'Add an attachment' link above.
This seems to be a problem with the browsing information provided by the server. It has | Listen louvre.intern.sigma-chemnitz.de:631 | SSLListen louvre.intern.sigma-chemnitz.de:443 and announces the printer 'bosch' both as | ipp://louvre.intern.sigma-chemnitz.de:631/printers/bosch | ipp://louvre.intern.sigma-chemnitz.de:443/printers/bosch When local cups sees such an announcement (which happens every 30 seconds) while a job has not completed yet, it reconfigures the printer and sends the job to the new address. I am not printing very much and can not say why I have not noticed this behavior earlier (I see it now with a downgraded f19 cups-1.6.4 too). Perhaps the printing was done faster and race not triggered hence.
You are using cups-browsed on Fedora 20 in order to discover the printers? Please attach /etc/cups/cups-browsed.conf.
yes; 'cups-browsed.service' is started with | BrowseRemoteProtocols dnssd cups | BrowsePoll louvre (no further non-comment lines in cups-browsed.conf) The rhel6 cups server has | Listen louvre.intern.sigma-chemnitz.de:631 | SSLListen louvre.intern.sigma-chemnitz.de:443 | | BrowseOrder allow,deny | BrowseAllow all | BrowseLocalProtocols CUPS | BrowseRemoteProtocols none | BrowseAddress 192.168.7.255 | Browsing yes
I think your cups-browsed.service configuration is wrong. Two or more of these are discovering the queues: - dnssd - CUPS Browsing - BrowsePoll You just need to remove whichever is not needed. E.g. if CUPS Browsing is working fine for your site, just have 'BrowseRemoteProtocols cups'. If BrowsePoll is needed, just have the BrowsePoll line. If dnssd is working fine, take a moment to identify whether native libcups discovery is sufficient or whether you really need cups-browsed for your site.