Trying to get CUPS working on HP-UX 11.11 and 11.31

[TroyBlang]

Hi

I have installed CUPS on both HP-UX 11.11 and 11.31.  The CUPS server is on Linux RHEL 5.  I have successfully printed the test page from both HP-UX servers.  I am now trying to print a plain text file from these servers to the CUPS server.  The printers I am using is a HP Laserjet 4000N and a Canon ImageRunner 2020.  When I print the plain text file it prints forever until I cancel the job.  It seems it is not finding the end of file marker on the text file.  I then converted the text file to a post script file and printed it and it is still printing until I cancel the job.  I see in the CUPS Gui mutiple print jobs of the same text file I was printing on HP-UX.  It does not matter if I convert it to postscript or not it is printing multiple times until I cancel the job on the HP-UX server.  It will print forever.  I have tried to change the configuration of the printer on the GUI.  Why is it that the postscript is printing forever also.  I see on the post script file the EOF at the end.  What am I missing.

[donna hofmeister]

(quoting bill...)

The recommendation is to setup all printers using HPPI with True End-of-Job off, and job recovery off. The code is convoluted in hpnpf (the network transport program for HPPI) and TEOJ causes a lot of problems due to the differences in handling the thousands of HP models (and some non-HP) too. The  purpose of TEOJ is to wait until the last page of a print job hits the paper tray. This requires interacting with the printer since multiple pages may have been buffered in memory. The printer is queried over and over to see if the last page is finished.

Start by deleteing and re-adding the printer using removequeue and addqueue:

removequeue -q printer_name

addqueue -q printer_name -h 12.34.56.78 -b off -r off -t off -i 123
(where -i 123 is the ID number for the printer)

[Dennis Handly]

>The recommendation is to setup all printers using HPPI with True End-of-Job off, and job recovery off.

Yes, but when using CUPS does this apply on HP-UX or the Linux CUPS server?

[TroyBlang]

Hi

The removeque and addqueue is this on the Linux CUPS server I do this or on each separate HP-UX Client Cups Servers.  Also what should I have configured on the Linux Cups Server for the Printers.  Right now I have lpd.  I have where I can set them to http, ipp, lpd and socket.  Let me know

[Bill Hassell]

addqueue and related tools from HPPI are for direct connect - no CUPS is involved. The advantage for CUPS is for the availibility of raster converters that support cheap printers. HP-UX has no support for any printing method except plain ASCII. Most cheap printers in the last 10 years,k regardless of manufacturer are labeled something like "Windows only" and this means nothing will print until the text is converted to dots that are compatible with the target printer. The big laser printers (HP and others) support plain ASCII printing so using a direct connect like addqueue (or the menu program hppi) will work fine.

Now for CUPS capability, you said it prints endlessly. So does it empty the entire paper tray, or does the job simply hang? The only common interface for printing is lpr/lpd which is called RFC 1179 protocol, a msort of send and pray protocol. No formatting, no printer status, etc. Did you add any CUPS tools to the HP-UX system?

[Matti_Kurkela]

Usually, when a print job repeats indefinitely, it is because something in the printing pipeline either produces an error or times out before the printer confirms it has completed the job, but the actual error is so minor that printer is able to produce output anyway.

The first step would be to find out which computer is responsible for the repeats: is it the HP-UX or the Linux system? If the HP-UXes are configured to send the jobs to the Linux system using the native CUPS printing protocol (i.e. ipp), then that would mean the Linux host is doing any required processing (e.g. passing the job through the "pxlmono" driver for the Canon ImageRunner 2020). Reading the CUPS logs might help here: the log messages should indicate which part of the printing pipeline is failing and hopefully also the reason for the failure.

Normal CUPS printing workflow is to convert everything to PostScript first, then produce a printer-specific format from the PostScript data if necessary. If the test pages were printed successfully and without extra repeats, that suggests a problem with the ASCII-to-PS part of the workflow: the test pages are generated already in PostScript format. Maybe CUPS wants to use some character set converter or another external utility but does not find it?

To understand your CUPS configuration better, would you please identify the CUPS versions used in both HP-UX and Linux? A "lpstat -t" listing from each system would be useful too.

As a workaround to avoid wasting paper, you should change the error policy setting (it should be settable separately for each printer in CUPS) to abort the print job if it has errors. This should be one way to do it:

lpadmin -p <queue name> -o printer-error-policy=abort-job

 You should find the same setting in the CUPS GUI too, if you prefer that.

[TroyBlang]

Hi

Yes the print job will print until the paper runs out of the tray and once you add paper to the tray it will keep on printing.  It seems it is only on HP-UX when I do the print jobs.  Linux printing works.  The versions I have for Linux and HP-UX are

Linux 1.3.7-30.e15

HP-UX 1.5.3

In order to install the CUPS on HP-UX I had to install all the other packages for CUPS to run on HP-UX.  I am using lpd connection. 

I have made the changes to abort-job on the CUPS Gui for all the printers.

When I run the /usr/local/bin/lp command on HP-UX it keeps printing

When I run the lp command on linux it prints one page like  it is suppose too.

lpstat -t on the Linux CUPS server

scheduler is running

system default destination: tcphpmis1

device for tcphpmis1:  lpd://tcphpmis1/queue

device for wdl14alhp5: lpd://wdl14alhp5/queue

device for wdl15gchp8: lpd://wdl15gchp8/queue

tcphpmis1 accepting requests since Thu 23 Aug 2012 01:18::28 PM CDT

wdl14alhp5 accepting request since Fri 31 Aug 2012 02:11:56 PM CDT

wdl15gchp8 accepting request since Fri 31 Aug 2012 03:40:50 PM CDT

printer tcphpmis1 is idle.  enabled since Thur 23 Aug 2012 01:18:28 PM CDT

printer wdl14alhp5 is idle.  enabled since Fir 31 Aug 2012 02:11:56 PM CDT

printer wld15gchp8 is idle.  enabled since Fri 31 Aug 2012 03:40:50 PM CDT

            Connected to wdl15gchp8...

/usr/local/bin/lpstat -t on HP-UX CUPS client server

scheduler is running

no system default destination

device for tcphpmis1:  ///dev/null

device for wdl14alhp5:  ///dev/null

device for wdl15gchp8:  ///dev/null

tcphpmis1 accepting requests since Fri Aug 31 14:07:28 2012

wdl14alhp5 accepting requests since Fri Aug 31 14:07:29 2012

wdl15gchp8 accepting requests since Fri Aug 31 15:18:31 2012

printer tcphpmis1 is idle.  enabled since Fri Aug 31 14:07:28 2012

printer wdl14alhp5 is idle.  enabled since Fri Aug 31 14:07:29 2012

printer wdl15gchp8 is idle.  enabled since Fri Aug 31 15:18:31 2012

Please let me know if you need anything else.

[Matti_Kurkela]

/usr/local/bin/lpstat -t on HP-UX CUPS client server
scheduler is running
no system default destination
device for tcphpmis1:  ///dev/null
device for wdl14alhp5:  ///dev/null
device for wdl15gchp8:  ///dev/null

"///dev/null"??? That's not quite right. I would have expected something like "ipp:/<linuxhost>/<printername>" instead, if you want the Linux host to act as a central spooler for all the printers using the CUPS native protocol (i.e. the Internet Printing Protocol).

Did changing the error policy stop the jobs from repeating, as intended?

I think something may be wrong in the CUPS printer configuration in the HP-UX system.

Exactly how did you configure CUPS printer queues on HP-UX?

Did you create a client.conf file to the CUPS configuration directory (I'm guessing /usr/local/etc/cups), to make the CUPS print job handling commands talk with the Linux server directly? Then you would not have to run the spooler on the HP-UX hosts at all, as the CUPS "lp" command would spool the print job directly to the Linux server.

Or are you letting the HP-UX systems' CUPS spooler to auto-discover the printers?

Or did you configure the printers manually to HP-UX CUPS?

The difference between HP-UX and Linux CUPS versions might be significant in the auto-discovery.

Try configuring a test CUPS remote printer explicitly using the lpadmin command on HP-UX, like this:

/usr/local/sbin/lpadmin -p test -v "ipp://<linux_hostname>/<printer_name>" -E -D "Test printer" -L "There"

Does this queue work better than the existing ones?

I hope you weren't using the -i option of CUPS lpadmin in combination with model scripts designed for the native HP-UX spooler: I would not expect that to work without carefully checking the model scripts' built-in assumptions first. If you need to do that for some reason, you might as well not use CUPS on HP-UX at all. In that case, you could install & enable the BSD-style LPD compatibility package of CUPS on the Linux system ("yum install cups-lpd && chkconfig cups-lpd on"), and use the native HP-UX spooler to send all jobs as-is to CUPS on Linux (by configuring the print queues as remote printers on the HP-UX native spooler).

(With the HP-UX native lpsched spooler or a (very) legacy BSD-style lpd, JetDirect network printers may not be natively supported by the spooler daemon, so the print queue must be defined using /dev/null as a device. The job is sent to the actual printer by piping it through a interface script(HP-UX)/print filter(BSD), which is customized to send a copy of the job to the printer as a "side effect". The "hppi" tool sets up the network printer queues for the native HP-UX spooler exactly like this. But CUPS can support network printers natively without such trickery.)

On the Linux host, you might have used the JetDirect printing protocol instead of the lpd protocol. But if the current configuration works, you should not change it at this time. (The printer URL for a JetDirect connection would be: "socket://<printer-hostname>:9100")

[TroyBlang]

Hi

Thanks the change to abort-job worked for not having it print forever.  Is there anything else I need to do on HP-UX that I might run into gotcha's later on.  It seems that HP-UX is different than Linux.  Linux is set up for CUPS and HP-UX needs all these packages for it to run.  Let me know.