NetBSD Problem Report #28593
From kilbi@rad.rwth-aachen.de Thu Dec 9 14:24:56 2004
Return-Path: <kilbi@rad.rwth-aachen.de>
Received: from linus.rad.rwth-aachen.de (linus.rad.RWTH-Aachen.DE [134.130.11.100])
by narn.netbsd.org (Postfix) with ESMTP id D447B251EB0
for <gnats-bugs@gnats.NetBSD.org>; Thu, 9 Dec 2004 14:24:54 +0000 (UTC)
Message-Id: <200412091424.iB9EOoUe024090@basis.lke.rad.klinikum.rwth-aachen.de>
Date: Thu, 9 Dec 2004 15:24:50 +0100 (MET)
From: Markus W Kilbinger <kilbi@rad.rwth-aachen.de>
Reply-To: kilbi@rad.rwth-aachen.de
To: gnats-bugs@netbsd.org
Subject: lpd problem/bug with 'port@host' entries and jetdirect/direct tcp printers
X-Send-Pr-Version: 3.95
>Number: 28593
>Category: bin
>Synopsis: lpd is handling jetdirect/direct tcp printers not properly
>Confidential: no
>Severity: non-critical
>Priority: high
>Responsible: bin-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Dec 09 14:27:00 +0000 2004
>Last-Modified: Thu Dec 09 21:45:00 +0000 2004
>Originator: kilbi@rad.rwth-aachen.de
>Release: NetBSD 2.0 and -current
>Organization:
>Environment:
System: NetBSD basis 2.0 NetBSD 2.0 (BASIS) #6: Mon Nov 29 10:14:17 MET 2004 root@basis:/usr/src/sys/arch/i386/compile/BASIS i386
Architecture: i386
Machine: i386
All machines/platforms
>Description:
For several months I was investigating the reason, why several
printjobs for jetdirect or other direct tcp (normally port
9100) printers (as kyocera's) failed (with '40 eio error's on
jetdirect, mostly showing some postscript errors on the
'final' paper sheet).
After looking at cups sources of their socket backend the
reason seems to be that these jetdirect printers require the
sending host to read back some message over the network
connection (where lpd at the moment simply ends with an
exit(0)).
>How-To-Repeat:
E. g. take a postscript print job which produces a stderr
meassage like '%%[ ProductName: HP LaserJet 4050 Series ]%%'
(Adobe's Postscript driver does this), send it via direct tcp
(lpd and port@host) to a jetdirect (postscript capable! :-))
printer and see how it fails.
>Fix:
The appended patch solves the problem completely for me (and
about 40 tcp capable print spoolers of our dept.). The
important part is the 'select' call itself (waiting for a sent
back message and timeout), which does not end with the
'timeout' normally. The (optional) read back of the sent back
message yields the above mentioned postscript stderr message.
This patch is only worth for template purposes... ;-)
I've chosen 'sw-bug' as category because so many jetdirect
devices are involved.
Index: lpd/printjob.c
===================================================================
RCS file: /cvsroot/src/usr.sbin/lpr/lpd/printjob.c,v
retrieving revision 1.39
diff -u -b -r1.39 printjob.c
--- lpd/printjob.c 7 Aug 2003 11:25:28 -0000 1.39
+++ lpd/printjob.c 9 Dec 2004 13:02:45 -0000
@@ -59,6 +59,8 @@
#include <sys/types.h>
#include <sys/file.h>
+#include<sys/socket.h>
+
#include <pwd.h>
#include <unistd.h>
#include <signal.h>
@@ -299,8 +301,37 @@
if (TR != NULL) /* output trailer */
(void)write(ofd, TR, strlen(TR));
}
+
+ /* That's what {Free,Open}BSD does */
+ /* , but it's not enough (still 40 eio errors) */
+ /* (void)close(ofd);
+ (void)wait(NULL); */
+
(void)unlink(tempfile);
(void)unlink(tempremote);
+
+ /* Stuff that is done in cups socket backend */
+ shutdown(pfd, SHUT_WR);
+
+ fd_set input;
+ struct timeval timeout;
+
+ timeout.tv_sec = 90;
+ timeout.tv_usec = 0;
+ FD_ZERO(&input);
+ FD_SET(pfd, &input);
+ if (select(pfd + 1, &input, NULL, NULL, &timeout) > 0) {
+ char buf[BUFSIZ];
+ int rlen;
+
+ if ((rlen = recv(pfd, buf, sizeof(buf), 0)) > 0) {
+ if (rlen >= sizeof(buf)) rlen = sizeof(buf) - 1;
+ buf[rlen] = '\0';
+ syslog(LOG_ERR, "Printer reply: >%s<\n", buf);
+ }
+ }
+ (void)close(pfd);
+
exit(0);
}
goto again;
>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: Markus W Kilbinger <kilbi@rad.rwth-aachen.de>
Cc: gnats-bugs@NetBSD.org
Subject: Re: bin/28593: lpd problem/bug with 'port@host' entries and jetdirect/direct tcp printers
Date: Thu, 9 Dec 2004 16:45:37 +0100
LOG_ERR for the return message sounds a bit drastic...
Martin
From: Markus W Kilbinger <kilbi@rad.rwth-aachen.de>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@NetBSD.org
Subject: Re: bin/28593: lpd problem/bug with 'port@host' entries and
jetdirect/direct tcp printers
Date: Thu, 9 Dec 2004 17:32:40 +0100
>>>>> "Martin" == Martin Husemann <martin@duskware.de> writes:
Martin> LOG_ERR for the return message sounds a bit drastic...
Sure! ;-)
My patch should only outline the problem / a solution. Also using
'recv' seems not appropriate for all kind of 'pfd', maybe even using
'ofd' would be the correct fd in this condition...
I hope bin-bug people will correct all my mistakes (and I will learn
from that) ... :-)
Markus.
From: Markus W Kilbinger <kilbi@rad.rwth-aachen.de>
To: David Brownlee <abs@NetBSD.org>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: bin/28593: lpd problem/bug with 'port@host' entries and
jetdirect/direct tcp printers
Date: Thu, 9 Dec 2004 19:54:05 +0100
Some additional notes on this topic:
My proposed patch just handles outstanding message data from the
pronter at the end of a print job what might be not sufficient!
Depending on the (postscript) print job much more message data can
accumulate (I can remember some page numbering messages for each page)
and fail the print job at an earlier stage. Maybe that's the reason
why cups socket backend checks for (and cond. reads) incoming message
data after each sent data block (8k in size), too.
- Is there an easy way to handle these incoming message data
independently from the output stream? Output data is sent quite
wildly spread in our source...
- Can input and output of a socket be handled by 2 different
processes?
- Can a socket's input independently/directly drained into /dev/null,
so the printer is satisfied that way?
Markus.
From: "Greg A. Woods" <woods@weird.com>
To: kilbi@rad.rwth-aachen.de
Cc: David Brownlee <abs@NetBSD.org>,
NetBSD GNATS submissions and followups <gnats-bugs@netbsd.org>,
NetBSD Bugs and PR posting List <netbsd-bugs@NetBSD.ORG>
Subject: Re: bin/28593: lpd problem/bug with 'port@host' entries and jetdirect/direct tcp printers
Date: Thu, 9 Dec 2004 16:44:20 -0500 (EST)
[ On Thursday, December 9, 2004 at 19:54:05 (+0100), Markus W Kilbinger wrote: ]
> Subject: Re: bin/28593: lpd problem/bug with 'port@host' entries and jetdirect/direct tcp printers
>
> My proposed patch just handles outstanding message data from the
> pronter at the end of a print job what might be not sufficient!
> Depending on the (postscript) print job much more message data can
> accumulate (I can remember some page numbering messages for each page)
> and fail the print job at an earlier stage. Maybe that's the reason
> why cups socket backend checks for (and cond. reads) incoming message
> data after each sent data block (8k in size), too.
Indeed it is quite possible for a print job on a true PostScript printer
to produce output at any time, and for it to produce pretty much any
amount of output too. E.g. fonts can be sent back, etc.
This is also why I use netatalk's printer interface with my Apple
LaserWriter instead of trying to use its builtin TCP/IP interface.
I've also tried to get afpd or papd or whichever it is to e-mail the job
output back to the user, but haven't had as much luck with that part
yet. Ideally though lpd would always do that....
However I would suggest that if lpd is going to read back any messages
from the printer that they should be logged in the error log file (LF)
and that they should also be mailed back to the user if possible.
(BTW, I've got a whole raft of other patches to usr.sbin/lpr that help
me avoid CUPS -- let me know if you want them! :-)
If I could avoid netatalk just for one printer I'd like to do that too!
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Secrets of the Weird <woods@weird.com>
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.