topic Re: Printing problem / how does it really work in Operating System - HP-UX

Printing problem / how does it really work

Raymond Wu - MTG — Mon, 04 Jan 2010 14:57:38 GMT

Ran out of space on /var due to another problem with SCSI timeouts.

People can submit print jobs but they're not getting printed.

I have down a lpstat -o... on the printer queues and there are nothing enqueued BUT when I go down into the requests subdirectory, they're are plenty of files there.

Tried restarting the spooler, disabliong and enabling the printers and nothing happens.

Help?

Re: Printing problem / how does it really work

Rita C Workman — Mon, 04 Jan 2010 15:29:43 GMT

First-

If yor /var is still full try running the 'cleanup -c ' command to get you some quick space. [ man cleanup ]

If your spooler is running try making sure your permissions aren't the issue:

Run

chmod 755 /opt/hpnpl
chown -R bin:bin /opt/hpnpl
chown -R lp /opt/hpnpl/tmp

Just a quick thought,
Rita

Re: Printing problem / how does it really work

TTr — Mon, 04 Jan 2010 15:46:38 GMT

If you can, shut down the system spooler (/sbin/init.d/lp stop). Then check for any processes that are owned by the lp user (ps -afu lp). There may be lp interface scripts that are in a hung state and you may have to kill them manually. After cleaning up all the hung lp processes start up the system spooler.

Re: Printing problem / how does it really work

Raymond Wu - MTG — Mon, 04 Jan 2010 15:46:44 GMT

Hi Rita,

/var/spool is at 90%

SAM says the spooler is running.

Did do patch cleanup - non-eventful.
and the permissions on /opt/hpnpl is 755; and the ownership is as you stated.

The thing that is bothering me is I do the following:
echo "test" | lp -dhphelpdesk
then lpstat -ohphelpdesk shows no entries
and lpstat -vhphelpdesk just shows the device as /dev/null but nothing is on the printer.

Re: Printing problem / how does it really work

Raymond Wu - MTG — Mon, 04 Jan 2010 15:50:25 GMT

lpsched isn't there.

Tried doing a /sbin/init.d/lp stop and /sbin/init.dlp start and it does say the line printer scheduler is started but I don't see a process lpsched.

Perhaps it is crashing?

Re: Printing problem / how does it really work

TTr — Mon, 04 Jan 2010 16:13:02 GMT

While the scheduler is down, did you check for orphaned processes owned by lp when the scheduler is down?
Also while the scheduler is down, try deleting /var/spool/lp/FIFO and /var/spool/lp/SCHEDLOCK. Then start lpsched.
If lpsched starts ensure the queues are accept-ed and enable-d.

Re: Printing problem / how does it really work

Raymond Wu - MTG — Mon, 04 Jan 2010 16:32:16 GMT

Hi TTR,

I did so a ps -afu and did see a entry for an entry for a remote printer that hasn't been utilized for months and killed the process.

I also see some SAM related processed in addition to I think the application interfaces to lp like Lawson lapm and Unidata unpm.

With the spooler down (lpstat -r shows not running) there was no FIFO and SCHEDLOCK files.

I starteded lp /sbin/init.d/lp start, the files FIFO and SCHEDLOCK are created.

I did a lpstat -a | grep -v accept and only thing that shows up is a redirect - FYI - I got over 300 printer queues.

Re: Printing problem / how does it really work

Rita C Workman — Mon, 04 Jan 2010 18:09:03 GMT

To each his own...I generally use lpshut and lpsched to stop/start print services respectively. That way you should see lpsched when you ps -ef.

Did you check the permissions/ownership settings????

/Rita

Re: Printing problem / how does it really work

TTr — Mon, 04 Jan 2010 18:27:24 GMT

Check if the permissions in /var/spool are good, all files (not soft links) should be owned by the lp user. If they are not change the owner to "lp".

The next thing would be to work with the pstatus, qstatus and outputq files in /var/spool/lp. They may have been corrupted when /var filled up. DON'T delete those yet, you will lose ALL the printer queues. You will need to restore those 3 files from tape.
First you make a copy of these files (even if they may be corrupted)

cd /var/spool/lp
cp pstatus pstatus1
cp qstatus qstatus1
cp outputq outputq1

Shutdown the lp spooler and then delete the originals
/sbin/init.d/lp stop
ps -ef |grep lpsched
rm pstatus qstatus outputq
rm FIFO SCHEDLOCK

Restore the 3 files from tape and put them in /var/spool/lp, ensure FIFO and SCHEDLOCK do not exist and try starting the spooler (/sbin/init.d/lp start).

Re: Printing problem / how does it really work

Raymond Wu - MTG — Mon, 04 Jan 2010 18:43:05 GMT

Hi Rita,

Yeah, I did - I think I actually posted that I checked for the permissions and they were set the way you said they should be.

I do not see a lpsched process out there but the lpstat -r command says the scheduler is running.

Ray

Re: Printing problem / how does it really work

Raymond Wu - MTG — Mon, 04 Jan 2010 19:29:51 GMT

I think I am at the point I need to ask again how exactly does printing work.

I have started lpsched -v so I see entries in the log files as my users are submitting their print jobs.

But again they don't get printed and when I do a lpstat-o on the particular queues, thgere is no entries. But when I do to the request subdirectory, there are entries under each of the printer queue names.

Am I confusing the two? Outstanding requests/enqueued items vs contents of request?

Re: Printing problem / how does it really work

TTr — Mon, 04 Jan 2010 19:55:48 GMT

Roughly, it is a two part process. First, the users use the "lp" command to *submit* their files to the printing system. The lp command takes the file along with the appropriate options and puts in in the /var/spool/lp/request/que-name as a print job (job sequence number) to be printed out. Second the lpsched monitors the spool area and when it sees a print job, it takes it and invokes one of the /etc/lp/interface/que-name scripts to actually send that print job file to the printer device.

It looks like the first part works correctly. But the lpsched part is not. Assuming you have checked everything else so far, it all points out to a corruption in the printer queue database, namely the 3 files I mentioned above.

Re: Printing problem / how does it really work

Raymond Wu - MTG — Mon, 04 Jan 2010 20:13:40 GMT

Hi Rita,

I did confirm everything under /var/spool/lp is in fact owned by lp with the exceptions of the symlinks which is owned by root.

As far as the copies, I assumed you had wanted me to copy them off with a ".1" at the end of it to preserve them prior to deleting them.

If I'm wrong, then oops but that's what I did.

I also assumed that you hade wanted me to try to print up the spooler with a new copy of each of the files saved off which I did.

Started the spooler and tried doing my quickie test of echo "test" | lp and didn't see it on the printer but did see it added into the request directory of the printer.

THere still is no lpsched process running tho.

Doing a restore is going to be a problem since we've been having backup issues and that's a different problem altogether.

Re: Printing problem / how does it really work

Albert Smith_1 — Tue, 05 Jan 2010 03:11:38 GMT

I have had this problem very often and here is what I do to clear it. THIS WILL CLEAR ALL PRINT JOBS

lpshut
cd /etc/lp/interface
cancel -e *
lpsched

queues should be clear at that point.

Re: Printing problem / how does it really work

Raymond Wu - MTG — Tue, 05 Jan 2010 12:58:37 GMT

Hi,

Just to let you all know that I reached out to you all because my support contract had lapsed w/o me knowing and I was in dire need. A parallel activity was to ram my renewal thru the pipeline and luckily for me I got the VAR to get me a courtesy call after I had the PO issued.

Karla of Singapore forwarded meea troublshooting document which right before me having to restore from backup the outputq, pstatus, and qstatus was to save them off and fire up a test print which worked. So then all was left was to apply a qucky script to re-submit the jobs stuck.

Thanks for all your help and suggestions.

Ray