Printers disabling automatically

[Shibin_2]

Hello,

One of my customer environment, HP-UX 11iv2, almost 500 print queues, which are distributed in many HP-UX servers. One of the server randomly disables the print queues. The queues that are disabling automatically, won't be always same. When issuing the enable command, it starts processing the job. After a day or two, either this queue or some other queues shows the same behavior.

At the same time, the same print queues works perfectly in other servers. We have recently applied the lpspool cumulative patch (PHCO_36976 s700_800 11.23 ) for this issue. But, the problem persists.

Anybody have suggestions ? Thanks in advance.

[Khairy]

hi shibin,

i have encounter similar problem like your several years ago.

This happen when 10-12 printer queues continues to pump excessively spool files to the all the 10-12 print servers.

Network is another contribution why the printer queues are down. There are a timeout value for the printer queues to stop communicating with the printer or print servers.

What i did was, i create a script which enable the printer queues every 15 minutes and that did the trick.

Really appreciate if you could assign some points if this answer yr question.

Rgds

[Shibin_2]

Hi Khairy,

Yo don't bother about the points, I will assign it later stage.

Thanks for your prompt response. What I observed that, this print queues are mostly disabling during the night time. Because, customer complains at morning :D ..

So, other than a script, anything else, there could be something else ??

[OldSchool]

so...does somebody perhaps power down the printers overnight, or could a cleaning crew be unplugging them?

If the printer is "off" and you print to it, its gonna disable...

I'm wondering if "some" of the servers have print jobs at night and others don't.

as noted, you could construct a script that looks for disabled printers and enables them early in the day.

[Steve Reynolds]

I too have an environment with hundreds of
printers. I use the attached script (executed by cron), to check and enable
any printers that have become disabled.

[skt_skt]

"If the printer is "off" and you print to it, its gonna disable.."

that is NOT true ; rather the print jobs are accepted, queued. The queue never get disabled..

[OldSchool]

Santosh...that may be your experience. Mine, on 9.x, 10.2 and 11.0 differs.

[OldSchool]

in my case, the printers were inadvertantly connected to "switched" outlets (lights off then printers were powered down).

depending upon the print volume, the printer would disable...I suspect the root cause was the spool dir filled up, but I can't verify that at this time

[skt_skt]

printer offline(still accessible in network) and printer printer powered OFF are different. So defintly the result is different too like what me and u experienced

[skt_skt]

also i would recommend

check "ps -ef | grep lpsched" and see if there are too many a multiple daemon running ? kill them and restart the spooler in a maintenance window if possible

[Shibin_2]

Hi All,

Thanks for the responses.

Santhosh,

As you suggested, there are lots of lpsched running and I have suspected this could be the problem and applied the patches, mentioned in the question.

But it looks, like effective was only for few days. Again the same issue happening. Secondly, all printers are alive 24hrs. When user says, print queue disabled, I can see the printer visible from network. So, this is not printer side issue, I believe. It must be lpsched issue.

Today early morning, I have done a following testing.

1. Shutdown the spooler
2. Started the spooler with -v option. i.e. #lpsched -v

This is because, once the spooler restarted, the problem won't come immediately. If it happens again, there could be much good information in /var/adm/lp/log file for further troubleshooting.

Let me see, how this is going to be worked out. Anyway, I am giving a low priority of cron job scheduling for this issue.

Some curiosity to investigate, why this happens. That's it.

[Shibin_2]

Hi all,

After restarting the spooler with -v option, I have found following error in the log file.

Parsing PJL: ecounter unexpected bytes
Parsing PJL: ecounter unexpected bytes
Parsing PJL: encounter PJL error

What is this error means? How can it be rectified? Could this be the real cause?

[skt_skt]

is that error associate with a particular queue?

folloiwng commands shows the supported formats like PDF/PJL/PS etc.

hpnpadmin -i IPADDRESSOFQ

[Shibin_2]

Hi Santhosh,

Thanks for the response.

I am not sure, this error related to any specific printer. After restarting the spooler with -v option, I can see this error intermittently in /var/adm/lp/log file.

When I searched with this in google, some of the ITRC forums says, it may be driver mismatch or driver related. If it is driver related, I have one question.

How can I find what are the printer drivers/scripts installed in the server? Because, we creates printer in one server and it replicates to others through a cron schedule.

[skt_skt]

addqueue -l

will list the drivers installed on the system. You may have to check the exact path for addqueue .

[/root] /opt/hpnpl/bin/addqueue -l|wc -l
82

[Shibin_2]

Hi Santhosh,

Thanks for the response.

I found the following one, when the printer goes disable state.

#lpstat -pWSTPRT27
printer WSTPRT27 disabled since Sep 3 10:31 -
error 1 returned
fence priority : 0

What is this error1 returned? This will be resolved, when I apply enable command.

[Sandeep_Chaudhary]

Is the same printer was working previously ?with same configuration?
have u restarted spooler?
have u deletede all stuck jobs in queue?
have u enable the printer using enable? command and it got enable?


If the answer is yes for all above question ur printer is having some hardware problem. please check.

[Shibin_2]

Hi guys,

I found one interesting info.

As I earlier said, we creates printer in one server and it replicates. The print server is HP-UX 11i and the problematic server is HP-UX 11iv2. Also, the problem reports on all remote printers. I have found that, the script using in HP-UX 11iv2 is HP-UX 11i. I think, this might be the root cause to give "error return 1". Engaged with HP Solution Center team.

Let's see, what they can suggest. Also, all other servers, replicating this printer, has the version same as the print server. So, no issues from that servers.

[skt_skt]

/opt/hpnpl/bin/transferqueue is applicable while mitrating/replicating from 11.11 to 11.23 which does some conversion from honp to hpnpl. But this are only applicable to jet direct/netowrk printrs. I did not observe any remote queues effected byt the migration/replication

[Manuel Contreras]

another printer command I didn't see mentioned is lpmgr

# /usr/sam/lbin/lpmgr -l > /tmp/lp.lst

# grep :no: /tmp/lp.lst
oakact01:remote:no:yes:oakact01_lj4k on 192.x.x.x:0: :

(printer is intentionally disabled )

lpmgr is your friend...

[Shibin_2]

Hi Friends,

Finally, I have rectified the problem and solved the issue.

Problem.

Printers creating in print server which runs on the OS version HP-UX 11iv1 and the problem that printers disabled in the server runs on HP-UX 11iv2. The problematic printers are only remote printers, not network.

Cause.

I have noticed, all the remote printers in HP-UX 11iv2 uses the rlp script version of HP-UX 11iv1, which is lower version with respect to the platform.

Resolution.

Recreated those problematic remote printers locally on the server that runs on OS version HP-UX 11iv2 and ensure that printer scripts uses the latest version that matches to the OS version. Also monitor the replication, whether it makes any changes on the script version, while replicates. Found, the script version is not at all changing on the replication and the printers are working perfect.

Hope, this will be very good information for those who has such kind of issue.

[skt_skt]

any idea how did u get the lower version of rlp with 11.23? Did u face the same problem with all 11.23 servers?

I do have a higher version of rlp on 11.23 by default
-r-sr-xr-- 1 root lp 73728 Jun 30 2007 /usr/sbin/rlp

[Shibin_2]

That couldn't identify, how the lower version came there. That was my concern in earlier questions too. Also, when I checked with Solution Center team, they too said, high possibility of copying the print server version itself. But how, that no idea.

[Shibin_2]

Solution described above.