09-02-2008 05:15 PM
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.
09-02-2008 05:25 PM
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.
09-02-2008 06:04 PM
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 ??
09-03-2008 11:34 AM
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.
09-03-2008 12:04 PM
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
09-03-2008 05:19 PM
09-03-2008 05:25 PM
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
09-03-2008 05:44 PM
Thanks for the responses.
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.
09-05-2008 04:12 PM
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?
09-06-2008 07:24 PM
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.
09-07-2008 04:58 PM
Thanks for the response.
I found the following one, when the printer goes disable state.
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.
09-07-2008 10:22 PM
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.
09-08-2008 12:25 AM
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.
09-08-2008 10:23 AM
09-08-2008 12:29 PM
# /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...
09-23-2008 10:42 PM
Finally, I have rectified the problem and solved the issue.
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.
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.
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.
09-24-2008 05:46 AM
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
09-24-2008 05:55 AM