Date: Sat, 24 Jan 2004 23:30:39 -0500 From: "Peter C. Lai" <sirmoo@cowbert.2y.net> To: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org, freebsd-ports@freebsd.org Cc: sirmoo@cowbert.2y.net Subject: lpt0 blocking i/o causes ghostscript to hang system Message-ID: <20040125043039.GG311@cowbert.2y.net>
next in thread | raw e-mail | index | archive | help
Hi. I have this peculiar issue with printing to lpt0 with ghostscript-gnu 7.05. I'm running stock lpd(1) with a handwritten input filter. If I am printing a huge file (such that the printer can't buffer all of the document at once and I am spooling to the printer as the printer is printing), and the printer starts blocking i/o (due to paper jam/paper out/etc), the ghostscript hangs the system until I unblock the parport (by remedying the condition, or hitting the "retry" button on the printer). It appears that ghostscript attempting to pipe its output trips interupts to the point that all of the cpu is taken up and the system will stop responding until the printer unblocks lpt0. My input filter is: #!/bin/sh exec 3>&1 1>&2 GS=/usr/local/bin/gs GS_FONTPATH=/usr/local/share/ghostscript/fonts:\ /usr/local/share/ghostscript/7.05/lib export GS GS_FONTPATH $GS -q -dNOPAUSE -dSAFER -sDEVICE=ljet4 -sOutputFile=/dev/fd/3 - && exit 0 exit 2 Now, if I don't use gs, and just use cat(1) as my passthrough filter like this: #!/bin/sh exec 3>&1 1>&2 /bin/cat 1>&3 && exit 0 exit 2 When i/o on lpt0 is blocking in this case, cat(1) will quietly sit there until such time that lpt0 can be written to again. I believe this is because cat(1) buffers its output. Right now my solution is to have ghostscript's -sOutputFile=\|"/usr/bin/lpr -h \ -Pbuffer" where a printcap(5) entry for the "buffer" printer's device is lpt0 and has an input filter that uses cat(1) (just like above). Here, gs will output the processed job to a "buffer" spool before any i/o is outbound to lpt0. Any of you run into this problem at all? It was seriously bugging me until I devised the 2 spooler system above, which adds stability to the system but feels too hackish for me. Whereas my print server is no longer hanging because someone is too lazy to put paper in it, the solution breaks my in-house web based job control system. The main culprit is gs not buffering its output; but lpd could also use a hand in "printer not-ready" detection. -- Peter C. Lai University of Connecticut Dept. of Molecular and Cell Biology Yale University School of Medicine SenseLab | Research Assistant http://cowbert.2y.net/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040125043039.GG311>