lpsched failing

[Phil Corchary]

I have a K570/HP-UX 11.0 system that I just became reponsible for that is a dev system for Oracle Fin. Little printing is actually done, but about 300 printers on the WAN are configured.

I'm told that lpsched "dies" frequently, and in fact the last sysdmin setup a frequent cron job to check and restart it.

I don't see anything that would indicate a problem. Where Do I need to look for hints? I've restarted lpsched -v -a at this point, and written a reliable script to restart it, but haven't seen it fail so far.

Ideas?

[Bill Hassell]

Start by searching for patches related to lp. And if you are using JetDirect network printers, ask the network administrator to monitor the health of the network. Same goes for remote printers where the data is shipped to another system for printing.

Since network printers are so common now, remote printing, especially to PC servers is of dubious value and introduces not only delays but higher than necessary complexity in a simple task (ie, printing).

lpstat -v for 300 printers may result in a fast growing lp log file...watch the size and since you're only interested in the end of the log (when something breaks), you can safely truncate the file, perhaps daily.

[Tim Malnati]

I agree with the patch comment. I would also make sure that you have a recent vintage of JetAdmin, assuming that you use it. I seem to remember a problem with it some time ago similar to this? In any event, the latest (vd.06.21) is available for download at http://www.hp.com/cposupport/swindexes/hpjetadmin1875_swen.html Otherwise, I wonder if either the pstatus or qstatus files are corrupt?

[Rick Garland]

I would think that the FIFO and SCHEDLOCK is being looked for. These are necessary files for the lp process to function.

Patches are always a welcome (and sometimes a godsend) solution to a problem. Check to see if you have any patches installed for lp and see what ones are available
that you haven't installed.