Large cups systems?

Seth Galitzer sgsax at ksu.edu
Tue Oct 16 09:26:16 PDT 2007


OK, now we seem to be getting somewhere.  Thanks to the changes I made
yesterday, now only jobs are getting stopped without blocking the whole
queue.

I had seven jobs stopped overnight, all plain PS files, all most likely
sent from Windows.  Of those seven, three were in the queue that I had
tried to use beh on and was stopped this morning.  When I resent them to
another printer, they all printed fine.  So that tells me, either I
didn't use beh correctly or at the very least, I just shouldn't use it.

The other four were on two different queues/printers (two each).  They
are all pdf files, all generated by Acrobat 8.0.  Here's a sample PS
header from one of them:

%!PS-Adobe-3.0
%cupsJobTicket: job-hold-until=no-hold
%cupsJobTicket: job-sheets=none,none
%!PS-Adobe-3.0
%%Title: ProjectCalendar[1].pdf
%%Creator: PScript5.dll Version 5.2.2
%%CreationDate: 10/12/2007 14:25:21
%%For: dag
%%BoundingBox: (atend)
%%Pages: (atend)
%%PageOrder: (atend)
%%DocumentNeededResources: (atend)
%%DocumentSuppliedResources: (atend)
%%DocumentData: Clean7Bit
%%TargetDevice: (LaserJet 5M) (3010.000) 550
%%LanguageLevel: 3
%%HiResBoundingBox: 18 23.2942 594 768.7059
%%CropBox: 18 23.2942 594 768.7059
%ADO_BeginApplicationHeaderComments
%%Creator: Adobe Acrobat 8.0
%%For: foo
%%LanguageLevel: 3
%ADO_EndApplicationHeaderComments
%%DocumentProcessColors: (atend)
%%DocumentCustomColors: (atend)
%%EndComments
%%BeginDefaults
%ADO_BeginApplicationDefaultsComments
%%ViewingOrientation: 1 0 0 1
%ADO_EndApplicationDefaultsComments
%%ViewingOrientation: 1 0 0 1
%%EndDefaults

Looking at the logs, I get errors with KID3 at some point, causing it to
fail early.  Here's a sample from the log for the above file after all
three pages get processed:


D [16/Oct/2007:11:03:10 -0500] [Job 2115] %%[Page: 1]%%
D [16/Oct/2007:11:03:10 -0500] [Job 2115] GPL Ghostscript 8.54:
Unrecoverable error, exit code 1
D [16/Oct/2007:11:03:10 -0500] [Job 2115] renderer return value: 1
D [16/Oct/2007:11:03:10 -0500] [Job 2115] renderer received signal: 1
D [16/Oct/2007:11:03:10 -0500] [Job 2115] Process dying with "Possible
error on renderer command line or PostScript error. Check options.",
exit stat: 3
D [16/Oct/2007:11:03:10 -0500] [Job 2115] error: Illegal seek (29)
D [16/Oct/2007:11:03:10 -0500] [Job 2115] Possible error on renderer
command line or PostScript error. Check options.
D [16/Oct/2007:11:03:10 -0500] [Job 2115] tail process done writing data
to STDOUT
D [16/Oct/2007:11:03:10 -0500] [Job 2115] KID4 finished
D [16/Oct/2007:11:03:10 -0500] [Job 2115] End of Embedded document,
nesting level now: 0
D [16/Oct/2007:11:03:10 -0500] [Job 2115]
D [16/Oct/2007:11:03:10 -0500] [Job 2115] Closing renderer
D [16/Oct/2007:11:03:10 -0500] [Job 2115] KID3 exited with status 3
D [16/Oct/2007:11:03:10 -0500] [Job 2115] Renderer exit stat: 3
D [16/Oct/2007:11:03:10 -0500] [Job 2115] Renderer process finished
D [16/Oct/2007:11:03:10 -0500] [Job 2115] Killing process 17976 (KID3)
D [16/Oct/2007:11:03:10 -0500] [Job 2115] Process dying with "Error
closing renderer", exit stat: 3
D [16/Oct/2007:11:03:10 -0500] [Job 2115] error: Illegal seek (29)
D [16/Oct/2007:11:03:10 -0500] [Job 2115] Error closing renderer
D [16/Oct/2007:11:03:10 -0500] [Job 2115] File 0 is complete.
D [16/Oct/2007:11:04:00 -0500] Unloading job 2115...

At this point, the first page has been printed, but the last two are
not, and the job goes into "stopped" status.  Other failed pdf jobs
exhibit the same behavior: partial printing (seems to be approximately
half the document) and then KID3 exits with status 3 and kills the process.

My next test will be to reprint the original document from another
version of acrobat (or other pdf reader) and see if I get the same
errors.  I'll keep you posted.

I feel like we're getting closer to an answer here.  Is it possible
acrobat is behaving badly?  Should I try a different engine (eg *not*
hpijs)?

You want me to provide more of the jobfile and error_log?  I can
pastebin them somewhere.  Just let me know if that would be helpful.

Thanks for your continued help.

Seth


Kurt Pfeifle wrote:
> Seth Galitzer wrote:
>> Kurt Pfeifle wrote:
>>> You should indeed grab the next few spoolfiles which provoke a "hanging
>>> job" and save them to somewhere else, and note down the target printers,
>>> the job settings used, etc.
>>>
>>> (The files will be in the original format as received by CUPS, prior to
>>> any filtering being applied).
>>>
>>> Then you can use these to try and reproduce the problem. You can also
>>> see if the files would print if you sent them to a different printer
>>> (model).
>>>
>> One more quick question for clarification: So I have the spoolfile, I
>> resubmit it with a simple lpr command, or just drop it back in the spooldir?
> 
> Re-submit it with "lpr -P printer1" or "lp -d printer333" to any printer
> you like.
> 
> Dropping to the spool dir will not change a thing.
> 
> Resubmitting it will create a new job with the same input file.
> 
> *HOWEVER* make sure you use the same commandline params that CUPS is
> seeing for that job (grep for "argv[5]" in the error_log). If it is
> a job originating from Windows, that goes unfiltered through CUPS be-
> cause of usage of native Windows printer drivers, then add the "-o raw"
> option.
> 
> And *IF* it is a Windows RAW file, you can only re-submit it to the same
> model family of printers.
> 
> Watch out if you notice any pattern for these jobs that make your printer
> hang. Which file types, sizes, submitting clients, commandline options,
> target printers, etc.
> 




More information about the cups mailing list