LP spooler causes endless printing of the same job

[Lothar Seitter]

Hi,

once a week we get an endless print job
which can be stopped only by disabling/enabling
the queue. Does anybody know this behaviour and
is there some solution!?

The environment is:
HP network printers of model type net_lj4x and net_lj4100. The print job is a "normal" pcl document which is printed with lp. When the print job is active the same document gets printed on hundreds of sheets until somebody turns of the printer or the paper is empty...
During this time the usual hpnpf process is visible in the process list.
The workaround for the problem is to run disable/enable on the queue.

Any help appreciated,

Lothar

[Leif Halvarsson_2]

Hi,

"once a week we get an endless print job"

Is it the same job every week ? Some scheduled printout or, some report printed once a week ?

And, is it perhaps something strange with this specific job, does normal printing work OK.

[Mohanasundaram_1]

Hi Lothar,

As requested in the previous post, more specifics of the problem would help.

The only reason why the same printout keeps printing is, the spooler considers that printer went off before completing a job.

Therefore the job is resubmitted for printing from the beginning. If this happens only with a particular printing job, then it is worth analysing the print job for any special characters.

With regards,
Mohan.

[Bill Hassell · Accepted solution]

There are two reasons for mu;tiple copies: lp was scheduled with the -n option. If this was from a script, perhaps an undefined or invalid variable was used with the -n option thus requesting 10,000 copies. You can verify this when the problem occurs by using lpstst to determine the current print job number, then go into the /var/spool/lp/request where you'll see a directory for each printer. Change directory to the printer having a problem and there will be two files for each print job: a control file and a data file. The control file starts with the letter "c" and has all the command line parameters stored in that file. The line that starts with K is the quantity. If it does not read: K1 then the -n option was used in the lp command for that print job.

The second is a network problem and for that, you'll need to enable hpnpf logging (which could create a large file if the print job is very large). The option is -ohpnpflog and must be included on the commandline with the problem report. The log will be stored in /opt/hpnpl/tmp/hpnpflog and should be watched to make sure it doesn't fill /opt. This is a detailed protocol trace for the network connection. Most likely, you'll see the connection getting reset and the job restarted. That is the source of the multiple copies.

Now why the connection is reset will take some more work. Does the problem occur with the exact same document or various documents? Or is the document custom-generated by some report-writer? The reason is that the document may be creating a PCL code that is incorrect for the printer and the printer itself is getting reset. To determine what the code is that is causing the problem, you can use the debugm option, as in lp -dprinter -odebugm/var/tmp/debugfile . The /var/tmp/debugfile will be exactly what will be sent to the printer. Use vi to look at the area where the printing restarts.

And the other possibility is network problems which will require more detailed work. You can try turning off the the TRUE-EOJ option in the JetDirect setup for the printer. Run hppi and modify the printer queue to disable TRUE-EOJ (in the Additional Options).

[Lothar Seitter]

>Is it the same job every week?

No, once a week is only the estimation of frequency. These are all different print jobs
created from a report writer.


> The only reason why the same printout keeps
> printing is, the spooler considers that
> printer went off before completing a job.

Went off or some other signal from the printer that the print job has failed. This is what I guess, too.


> lp was scheduled with the -n

Definetely not. We don't create copies on the spooler level.


> The second is a network problem

Yes. Network, printer or pcl seems very reasonable for me. Unfortunately I don't have
an example to reproduce the problem, but I am
trying the hpnpf log option as well as the debug option and the TRUE-EOJ flag. The last one sounds very interesting.

@Bill: Thanks a lot for this detailed information.

[Tommy Brown]

Lothar, We had problems with the "TRUE END OF JOB"
attribute. I always turn it off. It intermittently caused us problems until we did.
Tommy

[Bill Hassell]

And in case you have lots of JetDirect printers to fix, use the modifyqueu command as in:

for MYPRN in $(cat list-of-printernames)
do
/opt/hpnpl/bin/modifyqueue -q $MYPRN -t off
done

where the file list-of-printernames contains a list of JetDirect printer queues. (man modifyqueue)

[Steve McClendon_1]

Lothar,

I once had a similar problem and it was not the print job itsself but the job that printed just prior that left some control characters at the end which caused the next print job to get corrupted.

Once the right print job was identified, the queue was held and the output was examined prior to printout and the problem-causing control characters were identified.

Hope that helps.

Steve