On Thu, 4 Dec 2003 16:12:49 +0000 (GMT) Toby Blake <[EMAIL PROTECTED]> wrote:
> > Check "lpq -L" between jobs and find out if ifhp or lpd is causing > > the delay. If you have a long waitend delay or high waitend repeat > > (number of times to keep polling the printer for pagecount or status > > until the response stablizes), you will see such delays. > > I did include the output from the log file in my original message. > Here it is again: > > ---------------------------------------------------------------------- > Here's some (edited for clarity) information from status.pr: > > # here's a job that's just finishing... > > printing finished at 2003-11-27-14:33:14.630 ## > accounting at end at 2003-11-27-14:33:19.411 ## > finished '[EMAIL PROTECTED]', status 'JSUCC' at 2003-11-27-14:33:19.411 ## This is logging from "status.pr" or "status.<printername>". To find out if ifhp is holding things up with waitend status checking, you need a status file "status" in the spool directory of the affected printer. If there isn't one there, create one. This should collect output from ifhp itself (you've listed output from lpd, which is not the same). > There are a couple of important things to note: > > - we run our own print filters, not ifhp, in the example above the > last message from the filter immediately precedes the ... > > printing finished at 2003-11-27-14:33:14.630 ## > > ... line. > > So, I'm pretty sure it's nothing to do with the filtering process. > > - lpd talks directly to the printer on the Socket API port (9100), > i.e. the lp= line is ip.of.printer%9100 I didn't realize you were using your own filter for this... Can you run your filter on the command line without such delays? > > If ifhp is causing the delay, you many want to give some serious > > thought to changing your printcap to use an SNMP-based waitend > > rather than using HP's PJL implementation. > > What is used in the above case where lpd talks directly to the > printer? If lpd speaks directly to the printer, there is no end-of-job detection done. The job is handed off to the internal lpd server on the printer, and you hope for the best at that point. > We didn't get anything useful from lpd debugging, or at least nothing > I could see - the crucial point is that it seems to be waiting for the > subserver to exit. How can I debug the subserver - is it just another > lpd process? I seem to recall it is, so perhaps I could strace this > and see if that gives me any info as to why it's waiting. To capture more debugging info of subserver processes, you should be able to crank-up the debugging level for the printer using "lpc debug <printer> <debug_value>" and watch lots of output show up in the log file (defined in the printcap) for that printer. You can also use "lpd -F -D network+2 database+2 log+2" (or higher values) and see lots of output at the command line. -- ============================================================================ John Perkins | University of Wisconsin-Madison Associate Researcher | Department of Computer Science [EMAIL PROTECTED] | 1210 W. Dayton St. 608-262-0438/608-262-6626 FAX | Madison, WI 53706-1685 ============================================================================ ----------------------------------------------------------------------------- YOU MUST BE A LIST MEMBER IN ORDER TO POST TO THE LPRNG MAILING LIST The address you post from MUST be your subscription address If you need help, send email to [EMAIL PROTECTED] (or lprng-requests or lprng-digest-requests) with the word 'help' in the body. For the impatient, to subscribe to a list with name LIST, send mail to [EMAIL PROTECTED] with: | example: subscribe LIST <mailaddr> | subscribe lprng-digest [EMAIL PROTECTED] unsubscribe LIST <mailaddr> | unsubscribe lprng [EMAIL PROTECTED] If you have major problems, send email to [EMAIL PROTECTED] with the word LPRNGLIST in the SUBJECT line. -----------------------------------------------------------------------------
