Print jobs not entering unix print queue

[Terrence]

We have an rp7420 running HPUX 11iV2

Print jobs sent to a specific type of label printer are not even showing up in the unix print queue. Normally we disable the individual print queue to "catch" a job and then enable the queue to see if the job then leaves the queue.

However the job isn't even showing up in the queue.

These are intermec label printers and we use the dumb plotter driver (9998) on all of them.

All other printing is working fine.

I cycled the print scheduler and the /var/adm/lp/log file has nothing useful.

Ideas?

[Steven E. Protter]

Shalom,

What is the status of the print server. Is it enabled or disabled?

What about the /var/adm/syslog/syslog.log, there could be a message in there relevant to this situation.

Is the printer supported?

SEP

[Tim Nelson]

If all else fails, delete this print queue and re-create it. This could fix a corrupt spooler.

Network based printers are sometimes difficult to troubleshoot as their physical device is /dev/null and they simply execute a control script to open a socket and send the job. Could be one of any reasons why they do not work. permissions, script error, etc...

Post your /var/adm/lp/log, you never know what could be usefull.

[V. Nyga]

Hi,

have you already tested a simple print file
'll | lp -d'?

V.

[Terrence]

It turns out that the jobs are getting to /var/spool/lp/request/printname but they never get sent to the actual queue.

We suspect that /var/spool/lp/pstatus and/or qstatus might be corrupt.

Which is bad news for us since we would have to rebuild everything if true.

Strangely if we cycle the print queue normally it continues to have the problem. But if we cycle the queue with logging turned on (lpsched -v) printing starts working again.

[Bill Hassell]

You definitely have some corruption in the pstatus file which cannot be edited (it's a bunch of binary numbers). But you may not have to rebuild the complete spooling system. As Tim says, just delete the printer and add it back again. This should fix the problem. Turning logging on sort of implies that the problem may be small and the delete/add sequence will be successful. Also use SAM's save/restore spooler configuration. When your spooler is stable, save the config. Repeat when you make changes. Then when a problem shows up, use the restore spooler feature.

[Terrence]

Sorry I haven't been clear. It wasn't one label printer. It was all label printers. (More than 40).

Then we learned it wasn't just label printers, it was all printers. (More than 800).

We of course tried to delete then build a printer, but it had no effect.

So it's the entire spooler that's affected not just an individual print queue.

Our answer was to fail the server over to the other node in the cluster.

We're going to follow the procedure below to delete everything and then use scripts to recreate all the printers. Good times!

# lpshut
# cd /etc/lp
# rm */*
rm: interface/model.orig directory
# rm interface/model.orig/*
# cd /var/spool/lp
# rm FIFO SCHEDLOCK CLD_FIFO
# > default
# > outputq
# > pstatus
# > qstatus
# rm -r receive/*
# rm -r request/*
# /usr/sbin/lpsched -v
# lpstat -t
scheduler is running
no system default destination