Your message dated Sun, 12 Jul 2015 19:46:44 +0100 with message-id <[email protected]> and subject line Re: Bug#715800: cups: ipp backend gets stuck in "DEBUG: Validate-Job" loop has caused the Debian Bug report #715800, regarding cups: ipp backend gets stuck in "DEBUG: Validate-Job" loop to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 715800: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715800 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: cups Version: 1.5.3-5 Severity: normal Control: notfound -1 1.4.4-7+squeeze3 I'm trying to send a job via IPP to a network-attached Lexmark T640n printer. When i send the job, cups spawns a child process via /usr/lib/cups/backend/ipp which opens the network connection to the printer and then promptly gets stuck in some kind of horrible loop such that strace shows it doing only the following thing, ad infinitum (only two copies of the loop are shown below): 5575 write(2, "DEBUG: Validate-Job IPP/1.1\n", 28) = 28 5575 write(2, "DEBUG: printer-uri=\"ipp://cringer:631/\"\n", 40) = 40 5575 write(2, "DEBUG: requesting-user-name=\"dkg\"\n", 34) = 34 5575 write(2, "DEBUG: job-name=\"52927 - (stdin)\"\n", 34) = 34 5575 write(2, "DEBUG: document-format=\"application/octet-stream\"\n", 50) = 50 5575 write(2, "DEBUG: Validate-Job: server-error-internal-error (Success)\n", 59) = 59 5575 write(2, "DEBUG: Validate-Job IPP/1.1\n", 28) = 28 5575 write(2, "DEBUG: printer-uri=\"ipp://cringer:631/\"\n", 40) = 40 5575 write(2, "DEBUG: requesting-user-name=\"dkg\"\n", 34) = 34 5575 write(2, "DEBUG: job-name=\"52927 - (stdin)\"\n", 34) = 34 5575 write(2, "DEBUG: document-format=\"application/octet-stream\"\n", 50) = 50 5575 write(2, "DEBUG: Validate-Job: server-error-internal-error (Success)\n", 59) = 59 The first time the loop happens, between the "DEBUG: document-format=\"application/octet-stream\"\n" and the "DEBUG: Validate-Job: server-error-internal-error (Success)\n" we see this: 5575 poll([{fd=7, events=POLLOUT}], 1, 30000) = 1 ([{fd=7, revents=POLLOUT}]) 5575 sendto(7, "POST / HTTP/1.1\r\nContent-Length: 209\r\nContent-Type: application/ipp\r\nHost: cringer\r\nUser-Agent: CUPS/1.5.3\r\nExpect: 100-continue\r\n\r\n", 132, 0, NULL, 0) = 132 5575 poll([{fd=7, events=POLLOUT}], 1, 30000) = 1 ([{fd=7, revents=POLLOUT}]) 5575 sendto(7, "\1\1\0\4\0\0\0\1\1G\0\22attributes-charset\0\5utf-8H\0\33attributes-natural-language\0\5en-usE\0\vprinter-uri\0\22ipp://cringer:631/B\0\24requesting-user-name\0\3dkgB\0\10job-name\0\01752927 - (stdin)I\0\17document-format\0\30application/octet-stream\3", 209, 0, NULL, 0) = 209 5575 poll([{fd=7, events=POLLIN}], 1, 1000) = 1 ([{fd=7, revents=POLLIN|POLLERR|POLLHUP}]) 5575 poll([{fd=7, events=POLLIN}], 1, 30000) = 1 ([{fd=7, revents=POLLIN|POLLERR|POLLHUP}]) 5575 recvfrom(7, "", 2048, 0, NULL, NULL) = 0 (fd 7 is the TCP connection to the target printer, named "cringer"). It seems possible that the printer's crappy firmware can't handle this IPP directive, but that's no reason that the ipp backend should be stuck in an infinite loop trying. fwiw, i can print to this printer using lpd instead of ipp, and i used to be able to print to it via ipp when running cups from squeeze (1.4.4-7+squeeze3). the failure has only started with the upgrade to wheezy. If it makes any difference, the test job was sent using a simple: echo test | lp -d cringer - let me know if i can provide any further information to help debug this. Regards, --dkg -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-vserver-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cups depends on: ii adduser 3.113+nmu3 ii bc 1.06.95-2+b1 ii cups-client 1.5.3-5 ii cups-common 1.5.3-5 ii cups-filters 1.0.18-2.1 ii cups-ppdc 1.5.3-5 ii debconf [debconf-2.0] 1.5.49 ii dpkg 1.16.10 ii ghostscript 9.05~dfsg-6.3 ii libavahi-client3 0.6.31-2 ii libavahi-common3 0.6.31-2 ii libc-bin 2.13-38 ii libc6 2.13-38 ii libcups2 1.5.3-5 ii libcupscgi1 1.5.3-5 ii libcupsimage2 1.5.3-5 ii libcupsmime1 1.5.3-5 ii libcupsppdc1 1.5.3-5 ii libdbus-1-3 1.6.8-1+deb7u1 ii libgcc1 1:4.7.2-5 ii libgnutls26 2.12.20-7 ii libgssapi-krb5-2 1.10.1+dfsg-5+deb7u1 ii libkrb5-3 1.10.1+dfsg-5+deb7u1 ii libldap-2.4-2 2.4.31-1+nmu2 ii libpam0g 1.1.3-7.1 ii libpaper1 1.1.24+nmu2 ii libslp1 1.2.1-9 ii libstdc++6 4.7.2-5 ii libusb-1.0-0 2:1.0.11-1 ii lsb-base 4.1+Debian8+deb7u1 ii poppler-utils 0.18.4-6 ii procps 1:3.3.3-3 ii ssl-cert 1.0.32 Versions of packages cups recommends: ii avahi-daemon 0.6.31-2 ii colord 0.1.21-1 ii foomatic-filters 4.0.17-1 ii ghostscript-cups 9.05~dfsg-6.3 ii printer-driver-gutenprint 5.2.9-1 Versions of packages cups suggests: ii cups-bsd 1.5.3-5 pn cups-pdf <none> pn foomatic-db-compressed-ppds | foomatic-db <none> ii hplip 3.12.6-3.1 ii printer-driver-hpcups 3.12.6-3.1 pn smbclient <none> ii udev 175-7.2 -- debconf information: cupsys/raw-print: true cupsys/backend: ipp, ipp14, lpd, socket, usb, snmp, dnssd
--- End Message ---
--- Begin Message ---On Wed 10 Jul 2013 at 15:11:37 -0400, Daniel Kahn Gillmor wrote: > Brian Potkin writes: > > > Please see how the ipp14 backend performs. You might also want to look > > at bug #712719. > > Ah! thank you. Printing does work to this machine when i do > > lpadmin -p cringer -v ipp14://cringer/ > > So i'm sticking with that as a workaround for now. I think we will also go with that as a reason to close this report. Devices with defective IPP implementations are catered for with the ipp4 backend. Regards, Brian.
--- End Message ---
