AIX print queues going down frequently

[RC10]

I've gotten involved in transitioning a medical organization from their current AIX-based system to a new system. Part of that transition, which we've begun, involves setting up IP printers.

It seems that for any new printer we've set up, the queue goes down frequently (multiple times per day for some of them). I've read a couple of posts that might offer solutions but I'm not well enough versed in Unix to feel comfortable that I'm on the right track with them. I'm hoping to get some direction from the group on where to begin to troubleshoot this.

-Our AIX version is 4.3.3.0

-I can always ping the printers from the server.

-The server is old and overloaded - maybe this is part of the problem?

Thanks for any help you can offer!

Robert

 

[Antlersnbeards]

I'd keep an eye on your /VAR filesystem. Make sure that it is not full or nearly full. The ERRPT may give you some clues as to what is going on as well.

Antlers...

 

[sushveer]

Hi rc10

Print queue goes down due to the back end time out period
which is set at deafult value 90 sec while you are adding a print queue.

step 1:You check the print queue attributes for the parameter:backend time out period

You can check like this:

vi /etc/qconfig and check out for your print queue stanza
and for "backend = /usr/lpd/rembak

If u find like above ..it means that backend time out period is defaulted to 90 sec...then you have to edit the file like below line:

backend = /usr/lpd/rembak -T30
where 30 stands for 30min ...This is significant amount od time for getting acknowledgement for rembak from remote server.

While adding queues by using smitty tool....I recommend
to input some significant time in the parameter: Back end time out period(min)in smitty sub menus

roadmap for smitty:

#smitty spooler--->Add a print queue--->remote--->standard processing--->Back end Time out period(min)


That's it!
Please follow this and let me know the results...If the printer down problem persists...let us focus on some othee entity...
Good luck!

sushveer
IBM certified specialist-p-series AIX5L System Administration
AIX/SOLARIS/WEBSPHERE-MQ/TIVOLI Administrator

 

[RC10]

Thanks for the responses. . .

I've checked the /VAR.../@local/dev folder and the only files seem to be related to queue definition. Not sure how to check how "full" a folder is.

As far as the timeout goes, I'm suspicious that this isn't the problem for the following reasons:

-The queue seems to always fail when printing - response time is pretty fast (I can bring the queue up and watch it begin printing or crash again pretty much immediately - no 90 second delay).

-Print queues that were set up previously seem fine and there is no timeout other than the default.

Here are a couple of entries from the qconfig file. I'm having problems with SP64 but not SP75. I'm curious as to the purpose of the extra two entries in the SP75 entry and whether or not they're relevant. I've got another printer (SP81) that does not contain these entries and seems to work well.


SP64:
device = hp@SP64
hp@SP64:
file = /var/spool/lpd/pio/@local/dev/hp@SP64#hpJetDirect#9100
header = never
trailer = never
access = both
backend = /usr/lib/lpd/pio/etc/piojetd SP64 9100


SP75:
discipline = fcfs
acctfile = FALSE
device = hp@SP75
hp@SP75:
file = /var/spool/lpd/pio/@local/dev/hp@SP75#hpJetDirect#9100
header = never
trailer = never
access = both
backend = /usr/lib/lpd/pio/etc/piojetd SP75 9100

Please let me know your thoughts.

Regards,

Bob

 

[sushveer]

Hi RC10

In my earlier post ..I mentioned about the remote print queue and hence rembak backend program.But from your
latest post and the entries of qconfig file ..it is obvious that my earlier post doesn't suit to your printer config.



sushveer
IBM certified specialist-p-series AIX5L System Administration
AIX/SOLARIS/WEBSPHERE-MQ/TIVOLI Administrator

 

[RC10]

Queues were crashing all over the place this morning - any other suggestions?

Thanks!

Bob

 

[Antlersnbeards]

When I setup an remote HP queue here, I check to have the server do "local filtering before sending the job". Is this how you are setting up your print queues?


Dave Jackson

 

[Antlersnbeards]

Oh yeah....

To check to see how full your filesystems are run:

#df -k

This will show how big the filesystems are in Kilobytes and also show what percentage is used up.

100% used is BAD! )

Dave

 

[petertp6]

RC10:
use df to check if / , /var , /tmp these filesystems,
try to keep their usage under 70% and at lease 8~10MB free.
this will keep your system work fine.

if your /var is full, it will make printer subsystem stoped -- ALL printer queue can not be use.
So root cause of your problem should not bo filesystem usage.

fcfs is short for First Come First Serve -- no matter big or small job.
accfile is accounting for user/group's printed pages usage -- for cost charge in users/department if need.

Return to your problem,
Printer subsystem is fine due to other queue works.
Physical network is fine, because you can ping them.
Now we can focus in you printer/printer server.
Did printer work normal when your queue was down?
----such as 'not ready','out of paper','jam','no power' and so on.
If there is no one of them happen to your printer and it is in green condition,
Try to see setting of printer server (no matter it is a card within printer or a independent box).
If setting is right, try to replace another printer server with same setting.

Good luck!
Peter

 

[RC10]

Thanks again for the suggestions. Still not sure what's causing this, though.

Usually if the queue goes down, bringing it back up allows the queued jobs to start printing. In some cases, we have had to delete jobs from the queue because they were stuck.

I have tried pinging the printers when the queues go down and can ping no problem.

This is puzzling.