Print jobs get stuck in queue

[Anthony Villanueva]

Help!

It's been a couple of weeks since I began experiencing this problem!

What happens is that users send print jobs(in HPUX) to a remote printer(Win2K- which has its own printer spooler, Formtrap). Most of the time, the initial 2-3 print jobs go through. Then the rest seems to get stuck in the queue(in HPUX). The temporary solution I do is either disable/enable the remote printer in HPUX or stop/start the spooler.

I've checked both IP addresses of the HPUX and Win2k machines. I'm able to ping both ways. The services 515 isn't commented out in both machines and the "printer stream tcp nowait root /usr/sbin/rlpdaemon rlpdaemon -i" line in inetd.conf is also not commented out.

What could I be missing? Please help! I'm really getting desperate!

All help will be rewarded generously!

[Keith Bryson]

Have you got any errors in /var/adm/lp/lpd.log? If not, add the -l switch to the rlpdaemon line in /etc/inetd.conf to switch on logging. Watch the size of the logfile though!!

Keith

[Keith Bryson]

...and don't forget to re-start inetd using

inetd -c

Keith

[Mobeen_1]

Anthony,
Turn on logging as mentioned by Keith and throw at us any errors/messages you see in the log.

Lets see whats going on with your print queue )

rgds
Mobeen

[Steve Steel]

Hi


If it happens do an lpstat -t and see if the remote printer can be found

Also
lpshut
lpsched -v

Then you have a lot mor ein the spooler log


To me the connection hangs


Steve Steel

[Anthony Villanueva]

Hi Steve,

When the problem happens, i can see the remote printer using lpstat -t. I can also see the stuck up print jobs in the queue. It says "Printer now sending...." and the other print jobs in queue.

I already tried adding -l in inetd.conf but it wasn't creating any logs in the file /var/adm/lp/lpd.log. I also noticed that the lpd.log file is ownen by root(group-sys) so i changed it to lp-lp owner-group with a rw-r--r-- access.

I will be posting any logged messages ASAP.

thanks! and please, check on me from time to time.

[Anthony Villanueva]

...changed inetd.conf, added -l in rlpdaemon line.
then, run inetd -c in prompt....

will be sending print jobs to get the log going...

fyi...

[Anthony Villanueva]

Hi all,

I stopped the spooler(lpshut) then restarted it(lpsched -v) and it logged these messages in /var/adm/lp/log:

FIFO: Mar 12 11:00 q
FIFO: Destinations --
FIFO: inv_ylc: p enabled not busy /dev/null
FIFO: Printers --
FIFO: inv_ylc pid and id unknown
FIFO: Classes --
***** STOPPED Mar 12 11:00 *****
FIFO: Mar 12 11:00 l

And the lpd.log still doesn't have any messages...

[Anthony Villanueva]

additional log:

Start: TOPI_Off-4237 Sat Mar 12 10:45:59 CDT 2005
End: TOPI_Off-4237 Sat Mar 12 10:46:03 CDT 2005
/etc/lp/interface/model.orig/TOPI_Off nb
/opt/hpnpl/bin/hpnpf -j TOPI_Off-4237+frc -w -a1 -x 192.168.23.104
CHILD: Mar 12 10:46 TOPI_Off 4237 0000
FIFO: Mar 12 10:46 m TOPI_Off 3024
FIFO: Mar 12 10:47 r inv_ylc 4238 root toplunix 0
inv_ylc-4238 root inv_ylc Mar 12 10:47
CHILD: Mar 12 10:47 inv_ylc 4238 0000
FIFO: Mar 12 10:47 m inv_ylc 3110
FIFO: Mar 12 10:47 n
FIFO: Mar 12 10:53 r inv_ylc 4239 root toplunix 0
inv_ylc-4239 root inv_ylc Mar 12 10:53
CHILD: Mar 12 10:53 inv_ylc 4239 0000
FIFO: Mar 12 10:53 m inv_ylc 3257
FIFO: Mar 12 10:53 r T634_Fin 4240 frc toplunix 0
T634_Fin-4240 frc T634_Fin Mar 12 10:53
CHILD: Mar 12 10:53 T634_Fin 4240 0000
FIFO: Mar 12 10:53 m T634_Fin 3274
FIFO: Mar 12 11:00 q

[Bill Hassell]

THere isn't any additional change you can make to get this working. It does work for a while so basic things like inetd.conf are fine. The lpsched logging is fairly useful. What is the "inv_ylc" name in your system? Is it the queue name for the printer? If so, this looks like a permission/ownership problem. The SysV lp subsystem has almost no useful diagnostics so best you can do is to get your system patched to the current level. If you prefer selective patching, you'll need TCP/IP patches, lp spooler patches, possibly LVM and disk driver patches.

[Bill Hassell]

One additional thought: since the log reports that the pid is unknown, we can assume that something has terminated the lpsched process for this printer. Check /var/adm/syslog/syslog.log for console errors such as "table is full". Also run sar -v 1 and note if file or proc are very close to the maximum. Also run swapinfo -tm.

[Anthony Villanueva]

Hi Bill!

Glad to know that you're on my case!(i've been reading a lot about your reponses to similar issues)

anyway, yes, inv_ylc is the name of the remote printer. while the other one,TOPI_Off-4237, is a network printer

lastly, where can i get these patches and how do i know which one i need?

[Anthony Villanueva]

thanks bill,

will give it a try and let you know...

[Anthony Villanueva]

this is the result for sar -v 1

11:35:26 text-sz ov proc-sz ov inod-sz ov file-sz ov
11:35:27 N/A N/A 144/4136 0 821/4984 0 1670/8282 0

as for the swapinfo:
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 2048 79 1969 4% 0 - 1 /dev/vg00/lvol2
reserve - 496 -496
memory 717 348 369 49%
total 2765 923 1842 33% - 0 -
i also sent about 5 print jobs and all of them got stuck in the queue

[Anthony Villanueva]

this is in the /var/adm/lp/log file:

FIFO: Mar 12 11:29 n
FIFO: Mar 12 11:31 r inv_ylc 4244 ylc toplunix 0
inv_ylc-4244 ylc inv_ylc Mar 12 11:31
FIFO: Mar 12 11:32 r inv_ylc 4245 ylc toplunix 0
FIFO: Mar 12 11:32 r inv_ylc 4246 ylc toplunix 0
FIFO: Mar 12 11:33 r inv_ylc 4247 ylc toplunix 0
FIFO: Mar 12 11:33 r inv_ylc 4248 ylc toplunix 0
FIFO: Mar 12 11:33 n
FIFO: Mar 12 11:34 n
FIFO: Mar 12 11:36 r inv_ylc 4249 ylc toplunix 0
FIFO: Mar 12 11:40 n

[Anthony Villanueva]

Hi everyone,

I noticed this detail in the log:

When a user sends print jobs 1-5
the first one got through then the 2nd one gets stuck together with the rest of the jobs.
when i look at lpstat, it says "printer sending job 2..." but in the log file, /var/adm/lp/log, job 2 is already processed.
i cancelled job 2's id and then all went through.
i checked the recipient and all jobs including job#2, got printed!

[Anthony Villanueva]

It turns out I needed to reinstall the software in the remote end.

Now it's working fine!

Thanks everyone!

[Lily Wang]

Hi Anthony,

We are having the same problem when I upgraded our unix system from 10.20 sytem to a new 11.11 box. Can you tell me what kind of software that you updated in your remote server end? Have you done the patch thing in your 11.i system?

Thanks for your help!
Lily Wang