This chapter describes some of the common problems that might be encountered
in Advanced Printing Software and describes what steps can be taken to correct
the problems.
12.1 Solving Server Problems
This section contains descriptions of server errors that can occur during
normal print system operation.
Note that these errors are characterized as
server errors, but this does not necessarily mean that they are errors that
are caused only by spooler or supervisor objects; they can be caused by other
problems on the server host or the network environment..
12.1.1 Determining Which Server Processes Are Running
If a supervisor or spooler process is not responding to client requests, you can use the following command to determine which server processes are running:
# ps -ef | grep pdsp
If you do not see process entries for
pdsplr
,
pdspvr
, or
pdspvlpr
, make sure that you are looking
at the correct host.
To restart the missing server process, use one of the following commands:
# /usr/pd/lib/pdsplr # /usr/pd/lib/pdspvr # /usr/pd/lib/pdspvlpr
If the supervisor or spooler process is running but not responding to
client requests, you can use the
pdls
command to determine
the state of the object:
# pdls -c server -r all -s line server_name
If there is no response from the server, determine if the protoserver daemon is running:
# rpcinfo -u host 105004
If the protoserver is running, the following is displayed:
# program 105004 version 1.2B ready and waiting
12.1.2 Servers Running But Nothing Works
Use the procedure in
Section 12.1.1
to determine which
components are running, and which of those respond to the
rpcinfo
-u
or
-t
commands.
If the protoserver
does not respond, perform the following procedure to restart the print system:
Verify that the
/var/pd/pts
directory
is owned by nobody:
# ld -ld /var/pd/pts
Kill all
pdspvr
,
pdsplr
,
and
pdspvlpr
processes.
# kill -9
Send a hangup signal to
inetd
process:
# kill -HUP `cat /var/run/inetd.pid`
Try again to communicate with the protoserver daemon:
# rpcinfo -u host 105004
If there is no response or if
rpcinfo
returns
either of the following messages, "Program not registered" or "Connection
refused", stop and restart the
inetd
program:
# kill -9 `cat /var/run/inetd.pid` # /usr/sbin/inetd
Restart the print system spooler (pdsplr
)
and check whether you can now communicate with it:
# /usr/pd/lib/pdsplr servername # pdls -c server servername
If the spooler responds, then restart the other servers similarly.
If you are using CAA in a TruCluster Server environment, use the
caa_stop
and
caa_start
commands to stop and restart
Advanced Printing resources.
For example:
# caa_stop -f apx-default Attempting to stop 'apx-default' on member borzoi Stop of 'apx-default' on member borzoi succeeded. # caa_start apx-default Attempting to start 'apx-default' on member borzoi Start of 'apx-default' on member borzoi succeeded.
12.1.3 Supervisor Will Not Shut Down
In some instances, the
pdshutdown
command is not
fully effective in stopping a supervisor server.
In such cases:
1. Wait at least two minutes for the supervisor to exit.
2. Make sure the server is not actively printing jobs to printers by verifying that the physical printers are not in the printing state.
3.
Check for any paused jobs on printers.
The supervisor will not shut
down when jobs are paused unless you specify
-w now
with the
pdshutdown
command.
4.
If you still cannot stop the supervisor process, determine the supervisor's
PID and use
kill -9
to terminate it.
# pdls -c printer servername: printer-name printer-realization printer-state enabled ------------ ------------------- ------------- ------- LN17ps_PP physical idle yes LGP physical idle no Richs_PP physical idle no Sharie_PP physical idle no LN03R physical idle no ln17bert physical idle no lps17_sue physical idle no Null_PP physical idle no # ps ax | grep pds 29874 ?? I 0:00.64 /usr/pd/lib/pdsplr merle_spl 30481 ?? S 0:34.69 /usr/pd/lib/pdspvr merle_sup 5008 ttyp7 S + 0:00.02 grep pds # kill -9 30481
12.1.4 Spooler Will Not Shut Down
Use the same procedure as described in
Section 12.1.3,
to stop a spooler process.
12.2 Solving Job and Print Problems
This section contains descriptions of job and print errors that can
occur during normal print system operation.
Note that while these errors are
characterized as job and print errors, this does not necessarily mean that
the errors are caused only by print and job objects, they might be caused
by other objects in the print system.
12.2.1 PostScript Documents Print PostScript Program Code
Some applications that produce PostScript code incorrectly omit the
PostScript lead-in sequence
%!
.
If your document does not
begin with those characters, the print system supervisor incorrectly determines
that the file is a text file and translates it to a text listing rather than
letting the printer interpret it.
Re-issue the job and specify
document-format=PostScript
.
12.2.2 Physical Printer Is Hung in Connecting State
If an output device cannot be accessed when a job is assigned to it,
the physical printer object will remain in the
connecting-to-printer
state.
There are several reasons for this:
The printer is busy printing other jobs.
The printer is off line.
The printer is powered off.
The network path to the printer is inaccessible.
The printer is configured for bidirectional session control
(printer-connection-level=4
), but the device is not capable
of supporting this level.
The only way to return the printer object to
idle
is to remove the job.
12.2.3 Jobs Remain in Pending State
Use the following steps to determine why jobs remain in the pending state after they are submitted.
Make sure the physical printer is enabled and that its state
is
idle
.
Determine whether all job and document requirements, specified explicitly when submitting the job or implicitly by way of initial value objects, are both supported and ready on at least one physical printer associated with the queue.
For example, if you submitted a job to a logical printer whose initial
value objects specify
job-sheets
,
document-sheets
, duplex printing, number-up, etc., check that the corresponding
xxx-supported and
xxx-ready
attributes
are set on the physical printer:
# pdls -c p -r job-sheets-ready pp_name # pdls -c p -r document-sheets-ready pp_name # pdls -c p -r plexes-supported pp_name # pdls -c p -r number-up-supported pp_name
12.3 System Errors and Error Information
This section contains error and resolution scenarios related to subsystems
of the print system other than the printer and server objects.
In addition,
this section also contains information about where error information can be
located on the system.
12.3.1 Console Notification Does Not Work
If you do not receive any notification messages on the console, or if
mail notification messages are not being sent, determine if the console notification
daemon,
pdconntf
, is running by performing the following
steps:
Determine if the daemon is running:
# ps aux | grep pdconntf
If it is not running, try running it from a terminal window:
# /usr/pd/lib/pdconntf
12.3.2 Locating System Error Information
When an error occurs, Advanced Printing Software components report information by way of:
E-mail-The spooler and supervisor executables support
an option that sends e-mail to a designated administrator, when a startup
error occurs.
See
pdsplr
,
pdspvr
, and
pdspvlpr
reference pages for more information.
Events-When spooler and supervisor processes are properly running, they can issue events in the form of e-mail messages or console message notification. The events can report normal activities, such as jobs completing and printers changing state, or report problems associated with specific printers, queues, jobs, and servers.
Client messages-Client programs, such as
pdpr
,
pdls
, and
pdrm
, do not normally
display messages unless a problem occurs while processing the command.
However,
the message might not be sufficient to correct the problem.
Additional information
can be found in the client machine's system logs in
/var/adm/syslog.dated/current/lpr.log
.
To inspect the log files, you need root access.
If you have access
to the server host, you can find information logged in
lpr.log
on that host.
syslog-To control the number and severity of messages
in
/var/adm/syslog.dated/current/lpr.log
set the priority
value associated with
lpr
in the
/etc/syslog.conf
file.
Hewlett-Packard Company recommends the setting,
lpr.info
.
See
syslog
for more information on how to control the contents
of the
syslog
files.
The following types of information are stored in the system log files:
lpr.log
file at the
info
level.
lpr.log
file at priority levels
err
,
warning
,
notice
, and
alert
.
/var/adm/syslog.dated/current/lpr.log
on their respective hosts.
daemon.log
file.
lpr.debug
level, more detailed information
is produced, but its primary use is for software support specialists when
they are diagnosing a problem.
CAA log files-On a TruCluster Server system, the Cluster
Application Availability (CAA) subsystem controls the Advanced Printing Software
servers.
The CAA subsystem periodically monitors the spooler, supervisor,
and protoserver process to ensure that they are running and providing services.
If a failure occurs, the CAA script for Advanced Printing Software writes
error log information to the
/var/pd/apx_caa_resource_name.log
file.
If you encounter a command error and have made sure that the syntax is correct and the option values are correct, check the system logs for more information.