HPUX : Printer Issue

Backup/Restore the spooler configuration

It is good practice to create a backup of the spooler configuration every time you change it. Here's the command to save the configuration:
# /usr/sam/lbin/lpmgr -S -xsavedir=/var/sam/lp

This will save all configuration data to the directory: /var/sam/lp.

To restore your configuration later use :
# /usr/sam/lbin/lpmgr -R -xsavedir=/var/sam/lp

The corresponding SAM menu is: SAM : Printers and Plotters -> Save/Restore Spooler Configuration

Restarting the Spooling System

Restarting the spooling system on a regular system

First shutdown the line printer request scheduler:

# /usr/sbin/lpshut

scheduler stopped ß this is what you should see

Report the status of the line printer request scheduler:

# lpstat -r

scheduler is not running ß this is what you should see

Start the line printer request scheduler:

# /usr/sbin/lpsched

scheduler is running ß this is what you should see

Report the status of the line printer request scheduler:

# lpstat -r

scheduler is running ß this is what you should see

Restarting the spooling system in a printer package

If you want to restart lpsched on a system with a printer package, you must first check the status of the printer package (use cmviewcl) and if it's not running, then you can use 'cmmodpkg –e …' to re-enable the package autostart and/or 'cmrunpkg …' to restart the package. If the package is already running, then simply restart the scheduler with /usr/sbin/lpsched. Make sure you check for the existence of the lock file. That files needs to be removed if you want to have the cluster software monitor lpsched again.

First Troubleshooting Steps

Problems outside the LP spooling system might impact printing. Therefore it's always a good idea to start with checking /var/adm/syslog/syslog.log and dmesg.

Some examples:

a file-system full on /var/spool/lp may cause severe problems, like corruption of the spooler. Can easily be checked by:

$ bdf /var/spool/lp

Filesystem kbytes usedavail %used Mounted on

/dev/vgprnSAP/lvvarspoollpSAP

4112384 2514423 150048963% /var/spool/lp

Other messages like 'cannot fork' may also prevent LP from doing his work. If you see this, then check the setting of maxuprc. This parameters needs to be equal to (numberofprinters*3)+10. If it is less on a busy system you may run out of processes for the spooler.

Example:

$ kctune -v maxuprc

Tunable maxuprc

DescriptionMaximum number of processes for each non-root user

Module pm

Current Value 1200

Value at Next Boot 1200

Value at Last Boot 1200

Default Value 256

Constraintsmaxuprc >= 3

maxuprc <= nproc - 5

Can Change Immediately or at Next Boot

Now check the most obvious obstacle: is your scheduler running at all?

# lpstat -t |more

scheduler is running

...

If you see the following line instead restart the scheduler (see 'Restarting the spooling system').

# lpstat -t | more

scheduler is not running

...

If the scheduler says it's running check the remainder of your 'lpstat -t' output for any errors and check the spooler log file for any errors:

# more /var/spool/lp/log

lpsched: FIFO: Apr 1 04:21 n

lpsched: FIFO: Apr 1 04:21 r 1450 1333246910 0 912 0 0 90 hpx160 SAP_OPER MD45 -

MD45-912 SAP_OPER MD45 Apr 1 04:21

lpsched: CHILD: Apr 1 04:21 MD45 912 0000

lpsched: FIFO: Apr 1 04:21 m MD45 c 24798

…

If there are any errors you need to take a closer look at them. Sometimes they will point to permission problems or directories and files which are missing. Finding and resolving the cause of these errors should resolve the spooler hang. If for instance the request directory under /var/spool/lp is missing, you will see the following error message in the log file :

lpsched: can't open request directory

While lpstat may show:

# lpstat -t

...

cannot examine spooling area

...

Recreating the request directory either manually or by restoring it from backup will resolve the problem in the above case. If you do not see any obvious error messages in the log file proceed with the next step.

If there are no errors try to restart the scheduler (see 'Restarting the spooling system').
Sometimes the scheduler simply refuses to stop. 'lpshut' claims it stopped the scheduler but 'lpstat -r' still says it is running. If the restart does not solve the hang it is time now for the first step of the 'SpoolKick procedure'.

If you do not see the lpsched process running you very likely have a permissions problem with /var/adm/lp/log or any of its path components. To check the permission, please have a look at section: 'LP Spooler permissions'. Then try printing a test print job, and if your spooler still is hung proceed with the next step. Check the log file /var/adm/lp/log for any error messages.

SpoolKick Procedure

If you execute this procedure on one of the EMEA print packages, then it's good to first put the package in maintenance mode. This might prevent unnecessary package switching. See 'Notes on EMEA printer cluster package'. Don't forget to remove the lock-file after the problem is solved.

SpoolKick: First Step

Often the scheduler simply got into a situation where it can no longer finish all processes and delete its lock files. After doing all that manually, check if users can print again.

NOTE: If you cannot stop your users from submitting new print jobs while fixing the problem you need to find a way to prevent them from interfering with the spooler cleanup. It is difficult to correct a hung spooler while new requests keep being submitted. One possibility is to temporarily change permissions of the /usr/bin/lp command to '000'. Be aware that this can potentially cause problems with your application programs using the LP Spooler.

Shut down the scheduler:

# /usr/sbin/lpshut          

Are there still lp processes running ? 'lp processes' include lp, lpsched, interface scripts, hpnpg or lpstat processes.

# ps -ef | grep -E 'lp|hpnpf'

Kill all lp processes:

# kill <lp_process_id>

Check if all processes are really gone. If not, then use 'kill -9'.

# ps -ef | grep -E 'lp|hpnpf'

Delete temporary files, not all of them may exist:

# cd /var/spool/lp

# rm FIFO SCHEDLOCK CLD_FIFO Toutputq *.lock

Restart lpsched with additional logging enabled:

# /usr/sbin/lpsched -v –a

Check if the lpsched process is running:

# ps -ef |grep lpsched

NOTE: If you changed permissions on the lp command change them back to '4555'.

If printing still doesn't work, it's time for the second step.

SpoolKick: Second Step

If the cleanup of the temporary files didn't solve the problem, then probably the spooler outputq is corrupt. The only way to fix this situation is to clear the outputq and delete all requests in /var/spool/lp/request/<printer_name>/*.

This time you will lose ALL of the files that are currently scheduled for printing! So before you proceed find out whether your users can afford to lose their current print jobs. If they desperately need them, back those files up. The next step will tell you how to do all of that. But if your users are able to submit those jobs once again, it will be faster and safer to skip the first step and just ask them to print their old jobs after the spooler is back up. There are also limitations to the restoration of the options used for the print jobs, so we're not sure that all jobs will print correctly.

Make sure the spooler is down. (See above lpshut, kill, …)

Save all requests to a temporary directory:
# cp -rp /var/spool/lp/request /tmp/request
instead of /tmp/request you can use any other directory of your choice, you only need to make sure that you have sufficient space available

Now delete the requests
# rm /var/spool/lp/request/*/*
If (very) many printers are set up this might fail and you are better off using a script like the following :
#!/usr/bin/sh
cd /var/spool/lp/request
for i in *
do
cd $i
rm c*; rm d*; rm t*
cd ..
done

Now clean up the outputq on top of that. DO NOT DELETE this file, just delete its contents:
# > /var/spool/lp/output

Start the scheduler
# /usr/sbin/lpsched -v –aFdffasfasf

Print all requests again

After the spooler runs smoothly again all requests can be sent to their respective printers. The name of the directory in /tmp/request corresponds to the name of the printer the requests were sent to. All files starting with 'c' are 'job description files'. Your actual data files that you would like to print all start with 'd'. Files starting with 't' are temporary files and can be ignored. Below script will try to resubmit the files, and it will already try to process the –O options. Other options, like K (=number of copies), are silently ignored.

If different options were used with your print requests you have to find and use them when printing your jobs. For each data file that you wish to print there is a corresponding job file which lists all options invoked; f.i. for data file dA0096beach check cA0096beach:
# more cA0096beach
Hbeach
Proot
Jburnjet1-96
C
Lroot
BTitle <- title 'lp ... -t"Title"'
K3 <- number of copies 'lp ... -n3'
Onb postscript <- options used 'lp ... -onb -opostscript'
T/opt/hpnp/testfiles/ps<- original file to be printed
FdA0096beach
fdA0096beach
fdA0096beach
fdA0096beach
UdA0096beach
N/opt/hpnp/testfiles/ps
Mroot<- mail a message to user 'lp ... -m'
A4 <- priority 'lp ... -p4'

#/usr/bin/sh

OLDREQ=/tmp/request # this is the directory where you copied your files to !

cd $OLDREQ

for QUEUE in *

do

            DIR=${OLDREQ}/${QUEUE}

            cd ${DIR}

            for i in $(find . -mtime -1 -name 'c*') # only process recent files
            do

                        [[ $i != +(./c*) ]] && continue

                        name=${i#./c}

                        C=c${name}

                        D=d${name}

                        [[ ! -f $D ]] && { echo $D does not exist

                                                continue

                                                }

# dbg               grep "^O" $C

# dbg               echo $i $name $D

                        OPT=""

                        for option in $(grep "^O" $C)

                        do

                                    case $option in

                                                "O") continue ;;

                                                O*) OPT="${OPT} -o${option#O}" ;;

                                                -*) OPT="${OPT} ${option#O}" ;;

                                                *) OPT="${OPT} -o${option#O}" ;;

                                    esac

                        done

                        cat - <<-EOT

                        about to:

                        lp -d${QUEUE} $OPT ${DIR}/${D}

                        mv ${C} REQUEUED.${C}

                        mv ${D} REQUEUED.${D}

                        EOT

                        lp -d${QUEUE} $OPT ${DIR}/${D}

                        mv ${C} REQUEUED.${C}

                        mv ${D} REQUEUED.${D}

#                      echo "press enter to continue \n" # uncomment the lines to test

#                      read a # the script first on a few files

                        sleep 1 # the sleep is needed so we don't overload the spooler

            done

done

SpoolKick: Third Step

If the previous steps did NOT resolve your spooler hang most likely the configuration files are corrupt which are used by the spooler to determine which printers are set up and what their current state is. You should try to get those from your backup if available. If that fails too you have no other choice than to set up your spooler from scratch again.

There are several methods to restore a previously working printer configuration if your printer status files have become corrupt:

Restore pstatus and qstatus from backup
Stop the scheduler and recover the following files from backup:
/var/spool/lp/pstatus
/var/spool/lp/qstatus

Restart the scheduler and try printing.

If more than pstatus/qstatus have become corrupt you can recover the LP Spooler directories from your backup after stopping the scheduler:
/etc/lp
/var/spool/lp
/var/adm/lp

Use SAM to restore the spooler state. This assumes that you did save the spooler configuration previously. You can check the following directory if you are not sure that you have done so, it should contain your printer files:
# ll -R /var/sam/lp
See also: 'Backup/Restore the spooler configuration'

LP Spooler permissions

You can verify LP Spooler permissions by using the swverify command on the PrinterMgmt fileset:
# swverify -v -x autoselect_dependencies=false PrinterMgm

If the above command reports any errors or warnings check /var/adm/sw/swagent.log. Look for any kind of permission or ownership related problems. Correct the problems you find and try to restart the scheduler again.

Swverify will not check permissions of configured printers. If you still suspect a permission problem verify the LP Spooler directories: /etc/lp, /var/spool/lp and/var/adm/lp manually.

The permissions that should be set on the lp directories and configuration files, are listed here. Most of the directories are owned by user lp and group bin.

/etc/lp directory

drwxr-xr-x lp bin /etc/lp

/etc/lp contents

drwxr-xr-x lp bin cinterface

drwxr-xr-x lp bin class

drwxr-xr-x lp bin info

drwxr-xr-x lp bin interface

drwxr-xr-x lp bin member

drwxr-xr-x lp bin sinterface

/etc/lp/interface content

-rwxr-xr-x1 lp lp<size> <date> <time> <interface>

...

/var/spool directory

dr-xr-xr-x bin bin /var/spool

/var/spool/lp directory

drwxr-xr-x lp bin            /var/spool/lp

/var/spool/lp contents

prw------- lp lp CLD_FIFO

prw------- lp lp FIFO

-rw-r----- lp lp SCHEDLOCK

lr-xr-xr-x bin bin cmodel -> /usr/lib/lp/cmodel

lr-xr-xr-x bin bin fonts -> /usr/lib/lp/fonts

lrwxrwxrwx lp lp log -> /var/adm/lp/log

lrwxrwxrwx lp lp lpd.log -> /var/adm/lp/lpd.log

lr-xr-xr-x bin bin model -> /usr/lib/lp/model

-rw-r--r-- lp lp outputq

-rw-r--r-- lp lp pstatus

-rw-r--r-- lp lp qstatus

drwxr-xr-x lp bin receive

drwxr-xr-x lp bin request

-rw-r----- lp lp seqfile

lr-xr-xr-x bin bin smodel -> /usr/lib/lp/smodel

/var/spool/lp/request contents

drwxr-xr-x2 lp lp <queue>