Printer Scheduler

[bbhagwat]

I have the following HP UX server which is used for printing.

Release:   HP-UX B.11.31

The problem I am facing is that the printer scheduler goes down very often (there is no pattern that is observed). As a result of this all the print jobs get stuck in the queue. The only option left with me is to use lpsched to start the scheduler.

Can you please let me know if there is a permanant solution to the mentioned issue (maybe a patch??)

Please help me with this. Also, let me know if you need more details.

Many thanks for your help!

BR,

Bhushan

P.S. This thread has been moevd from Patches to HP-UX > sysadmin. - Hp Forum Moderator

[Ken Grabowski]

Having the latest patches on your system is always a good idea. But you should first see whats causing the problem.  What is written to /var/adm/lp/log?  Any corresponding events in /var/adm/syslog/syslog.log?  Is there enough free space in the file system where /var/spool/lp is? Is there any pattern to the lpsched failures? Do you do anything monitoring the lpsched process and free space in /var/spool/lp?

[bbhagwat]

Hello Ken,

Hope you are doing well! Thank you for your quick response.

Unfortunately there is no pattern to the scheduler failure.  Hence, in order to check the logs or events i will have to wait till the time the scheduler goes down :| 

For me the disk usage looks Ok. Please correct me if I am wrong here. 

/var # df -k /var/spool/lp

/var (/dev/vg00/lvol8 ) : 8885664 total allocated Kb
3716464 free allocated Kb
5169200 used allocated Kb
59 % allocation used

BR, 

Bhushan

[Bill Hassell]

>> df -k /var/spool/lp

You will find that bdf is more friendly than df:

# bdf /var/spool/lp
Filesystem          kbytes    used   avail %used Mounted on
/dev/vg00/lvol8    8885664 5169200 3716464 59% /var

You can look at the log files anytime. syslog.log and lp.log are time-stamped so look at the logs when the last spooler lock-up occurred. Also look at the command:

# dmesg

Unfortunately there is no timestamp but it will indicate system error messages when they occur.

Since the lp spooler is likely printing to network printers, there may not be a specific patch that fixes all lock-ups. You may have a filesystem full, a temporary network path error, possibly a kernel parameter is causing the error. Also, it is very helpful to provide the hardware model and HP-UX version you are running.

[bbhagwat]

Hello Bill, 

Here is the output for size, model no n extract from machine info, 

# bdf /var/spool/lp
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol8 8912896 5428976 3458592 61% /var

# model
9000/800/rp3440

# machinfo
CPU info:
1 PA-RISC 8800 processor (1 GHz, 64 MB)
CPU version 5
2 logical processors (2 per socket)

Memory: 6142 MB (6 GB)

FenGPS1:/var/adm/lp # uname -a
HP-UX  B.11.31 U 9000/800 391196332 unlimited-user license

The last occurence of scheduler going down was on Dec 16. I checked the syslog.log for the same. But could not find any specific mention related to scheduler. Is there anything I should grep for? (i might be missing). The most common entry in the syslog.log for Dec 16 is as below, 

Accepted password for <user name> from <IP> port 3680 ssh2. 

Apart from this following entries are there, 

smbd[5468]: [2014/12/16 14:10:09, 0] lib/util_sock.c:536(read_fd_with_timeout)
smbd[5468]: [2014/12/16 14:10:09, 0] lib/util_sock.c:1509(get_peer_addr_internal)
smbd[5468]: getpeername failed. Error was Invalid argument
smbd[5468]: read_fd_with_timeout: client 0.0.0.0 read error = Invalid argument.
smbd[1135]: [2014/12/16 17:01:25, 0] lib/util_sock.c:536(read_fd_with_timeout)
smbd[1135]: [2014/12/16 17:01:25, 0] lib/util_sock.c:1509(get_peer_addr_internal)

Is there anything specific that i need to check?

BR,

Bhushan

[Bill Hassell]

Accepted password for <user name> from <IP> port 3680 ssh2. 

 Noise (informational) for ssh logins.

smbd[5468]: [2014/12/16 14:10:09, 0] lib/util_sock.c:536(read_fd_with_timeout)
smbd[5468]: [2014/12/16 14:10:09, 0] lib/util_sock.c:1509(get_peer_addr_internal)
smbd[5468]: getpeername failed. Error was Invalid argument
smbd[5468]: read_fd_with_timeout: client 0.0.0.0 read error = Invalid argument.

These are more troublesome messages, indicating possible networking errors. smbd is the Samba (CIFS) file/printer sharing protocol. Are your printers setup using Samba or simply remote or JetDirect printers? Using Samba for printing introduces a *lot* of additional code and networking protocols into the printing process. Are your printers all HP models? If not, do the printers support port 9100 printing? If so, I would recommend reconnecting one printer using port 9100 (addqueue command) and testing that connection.

Also, when the spooler goes down, do you mean that a few printers stop printing? Or does lpstat show the spooler as not running?

[bbhagwat]

Hello Bill, 

I guess the printer setup is using SAMBA (I am not entirely sure since i am new to this altogether), Is there anything I can do to verify this?

All printers are HP Laser Jet printers. (majority of them are network printers, very few are remote). 

Yes. The printers do support printing through port 9100. 

When the spooler goes down  - All the printers stop printing. Executing the command lpstat -r shows that scheduler is not running. Hence, lpsched command is executed which starts the scheduler (again executing lpstat -r  shows scheduler is running) .  

The trouble I am facing is that the scheduler goes down often. No pattern is observed. Also, there is no prior notification that the scheduler is down. The only way I get to know is that when a user informs me that he/she is having issues printing (docs not being printed). Afterwhich i log in and check lpstat -r and it indicates that scheduler is not running. The moment i start the scheduler using lpsched the scheduler starts and all print jobs are executed. 

I want to go to the root of this issue and do whatever it takes to fix it (with all your kind and awesome help). :-)

Wish you all a merry christmas and a fantastic new year ahead!

BR, 

Bhushan

[Bill Hassell]

The file:  /var/adm/lp/log
probably has some details since the entire spooler (lpsched) is being stopped.
However, lpsched doesn't log a lot of useful info except start/stop.
To see more, see man lpsched -v.

To check SAMBA configuration, use this command:

grep printer /etc/opt/samba/smb.conf

There is a sample printer in this file but if you have a lot of "printer =" lines, then you are probably using SAMBA for printing. Unfortunately, SAMBA introduces a *LOT* of complexity into printing including authentication to windows and reliance on windows systems to perform printing. You can look in the log file specified here:

grep "log file" /etc/opt/samba/smb.conf

If the printer list is just a sample printer in the smb.conf, then look at the spooler directly:

lpstat -v

There are four types of printer connections:

-- serial or parallel cables (almost never used today)
-- DTC LAN appliance (should have been retired 10 years ago)
-- remote printer to another system, either Unix or Windows
-- network printer using port 9100 (aka, JetDirect protocol)

Of all the printer connections, only the port 9100 connection is the most reliable and easiest to troubleshoot.
When you list all the printers:

lpstat -v

you'll see "remote to" for printers that are actually attached to other machines. The details are:

device for <printer_queue>: /dev/null
remote to: <printer_name> on <remote_server>

These printers use the very primitive port 515 protocol with almost no diagnostic capability. The <printer_queue> is the name in the HP-UX stsem for printing. <printer_name> is the name of the printer on the remote system and <remote _server> is the system with the actual printer.

For port 9100 (JetDirect) style printers, there will just be "device for:" but not a second line. To ID these printers, use this command:

grep PERIPH= /etc/lp/interface/*

So troubleshooting each type of printer connection will require more details about the setup. The above all assumes that yu are not using one of several 3rd party software for printing.

Do you have any documentation about this system?

[bbhagwat]

Hello, 

Majority of the printers are  network printer using port 9100 (aka, JetDirect protocol). 

Now, yesterday the scheduler went down due to which the printer stopped functioning. Executing lpsched resolved the issue. Can you please help me in what exactly i need to check and where?

BR, 

Bhushan

[Bill Hassell]

If you did not start lpsched with -v, then there won't be any spooler details to look at. If there is nothing in syslog.log at the time the spooler stopped, then there isn't much to suggest except to add all the lp spooler patches.  The is a particularly annoying subsystem due to the lack of diagnostic information.