![[Previous Section]](b_prev.gif){kind=small}
![[Back to Table of Contents]](b_toc.gif){kind=small}
![[Next Section]](b_next.gif){kind=small}
Personal System Administration Guide |
This chapter contains detailed troubleshooting information on these topics:
"Responding
to System Monitor Warnings"
"Troubleshooting
Disk Space Problems"
"Troubleshooting
Problems with Removable Media"
"Rebuilding
System Setup Information"
"Troubleshooting
Shared
Resources
Problems"
"Troubleshooting
Network Errors"
"Troubleshooting
Standard Printing Problems"
The System Monitor keeps track of system activity, and notifies you when a critical error has occurred or is about to occur. It also provides online help that often gives you enough information to solve the problem. Always respond to these messages as quickly as possible to avoid losing valuable information.
To change the way the System Monitor notifies you of problems, or to turn off notification altogether, use the System Error Settings control panel; to start it, click the words System Error Settings now.
To get more detail on a particular message, you can open the System Log Viewer by choosing "View System Log" from the System toolchest, or by clicking the words View System Log now.
For information on managing and freeing up disk space, see Chapter 6, "Managing Disk Space."
When you insert a floppy disk, floptical disk, SyQuest disk, CD, or tape into a drive, the drive's icon should change to show that it recognizes the new media.
If the icon doesn't change within one minute of inserting the media, eject the media using the hardware eject button, and insert it again. (The system sometimes takes up to 30 seconds to recognize tape media.) If the system still does not recognize the media, save your work, and restart the system by choosing "Restart System" from the System toolchest. After you log in, the system should show the inserted media.
If the floppy icon changes to generic drive icon, or if you ever double-click the floppy icon and see an error message that says "Unknown Device", there is an unformatted floppy or floptical disk in the drive. To format it, eject the disk, then see "Formatting Floppy and Floptical Disks".
If you are trying to copy files onto a disk that's formatted for DOS files and you get an error message that says "I/O Error", your file names are too long or do not conform to the DOS naming conventions. DOS file names can contain no more than eight characters, a period (.), and a three character extension (for example, projects.exe uses the maximum file name length).
In very rare cases, the data that the system stores to identify users, systems, peripherals, and system setup information may become corrupted. If this happens, you'll see an error message that reports that system setup information has been lost or damaged, and refers you to this section on rebuilding the information.
You should follow the steps below only when you see such an error message. After you rebuild the information, no users will have administrative privileges except for the Administrator, and the system will have no Primary User. You need to use the User Manager to designate a Primary User and each Privileged User.
To rebuild the information, follow these steps:
Log in as root through a shell window.
Choose "Unix Shell" from the Desktop toolchest.
Position your cursor within the new window and type:
login root
Type:
/etc/init.d/mediad stop
/etc/init.d/cadmin stop
/etc/init.d/cadmin clean
/etc/init.d/cadmin start
/etc/init.d/mediad start
Wait for about five minutes, then try the operation again.
If you cannot share resources, or cannot drag shared resources from other systems on to your own desktop, either the optional NFS software is not installed or is not turned on, or an important NFS utility called automount probably is not turned on.
Only the Administrator can turn NFS and automount on since you need to log in as root. Follow these steps:
Log in as root through a shell window.
Choose "Unix Shell" from the Desktop toolchest.
Position your cursor within the new window and type:
login root
Check whether NFS is installed and turned on by typing:
chkconfig | grep nfs
NFS is installed and turned on if you see this line:
nfs on
Go on to step 3.
NFS is installed but not turned on if you see this line:
nfs off
Turn it on by typing:
chkconfig nfs on
Then go on to step 3.
If the system prompt returns with no information about NFS, it is not installed. See "Installing Software."
Type:
chkconfig automount on
/etc/init.d/network stop
/etc/init.d/network start
Close the shell window by typing:
logout
Restart the system by choosing "Restart System" from the System toolchest.
When you see error messages when you try to perform an operation that uses the network, wait for a few minutes, then try the operation again. The network may just be temporarily overloaded.
If the operation cannot succeed after a few tries, test the connection by following these steps:
Choose "Unix Shell" from the Desktop toolchest.
Use the /usr/etc/ping command with the hostname of a system that appears in your Networking tool. For example, if the remote hostname is mars, type:
/usr/etc/ping mars
Then press <Enter>.
If your system can reach the remote system, you see messages similar to these:
PING mars (192.0.2.2): 56 data bytes 64 bytes from 192.0.2.2:icmp_seq=0 ttl=255 time=0ms 64 bytes from 192.0.2.2:icmp_seq=1 ttl=255 time=0ms 64 bytes from 192.0.2.2:icmp_seq=2 ttl=255 time=0ms
These messages will repeat indefinitely; to stop them, press <Ctrl-C>.
Your connection is working; try the operation again. If it still fails,
see "Troubleshooting
Network Errors in the Desktop".
If your system cannot reach the remote system, you see only one line similar to this:
PING mars (192.0.2.2): 56 data bytes
Or you may see a line similar to this:
ping: mars: Unknown host
Press <Ctrl-C>, then try the ping command with a different hostname. If this does not work, go on to the next step.
Check the console window for error messages.
Position your cursor over the console icon, click the left mouse button once, and look for this message:
ec0: no carrier: check Ethernet cable
If you see this message, the physical connection between your system
and the network is not working. Make sure the Ethernet cable is firmly
connected to your system, then go back to step 2.
If you do not see this message, go on to step 4.
A Privileged User should make sure TCP/IP is turned on, and, if yours is an NIS network, make sure NIS is turned on and the correct NIS domain name is entered.
Start the Network Setup tool by clicking the words Network
Setup now.
Make sure there is a check in the box next to Turn on networking
for this port, and in the box next to Turn on NIS. Also make
sure the correct domain name appears.
If you made changes, click OK, and try using the network again. If it still doesn't work, restart the system by choosing "Restart System" from the System toolchest, and try again.
If you did not make any changes, click Cancel, and contact your network administrator to report that your network connection is not working correctly.
If the network connection is working, but you still cannot perform a network operation (such as searching for remote drives), check to see whether the objectserver is running . Follow these steps:
Choose "Unix Shell" from the Desktop toolchest.
In the shell window, type:
ps -ef | grep objectserver
You should see three lines whose last columns show:
/usr/Cadmin/bin/objectserver /usr/Cadmin/bin/objectserver grep objectserver
If all three lines appear, the objectserver is fine. Go on to
step 3.
If one or no lines show /usr/Cadmin/bin/objectserver, the Administrator should stop and restart it by logging in as root and typing:
/etc/init.d/cadmin stop
/etc/init.d/cadmin start
Wait one or two minutes, then try the operation again. If it still doesn't work, go on to step 3.
If the objectserver is running on your system, either the objectserver is not running on the remote system that you're trying to access, or no directoryserver is running on your local network.
Contact the Administrator of the remote system to check whether the
objectserver is running on that system using the commands shown
in step 2. If the Administrator had to restart it, wait a few minutes,
then try the operation again.
If the operation still does not work, ask your network administrator to check the master system to make sure the directoryserver is running on your local network. The network administrator should type:
chkconfig | grep directoryserver
The directoryserver is not running if the system shows this line:
directoryserver off
To turn it on, the network administrator should log in as root, and type:
chkconfig directoryserver on
/etc/init.d/cadmin start
It takes up to an hour for the directoryserver to gather all the information. Try the operation periodically until it works.
Note: The directoryserver should run on only one system in a particular subnet. If it runs on several systems, system performance will decrease, and search results may not be accurate.
Once you've used the Printer Manager to set up the printers that you want to access, printing files is usually very straightforward - you ask an application to print a file, then pick up your completed job from the printer.
The work that the system does to make files print, however, is fairly involved - especially when you are sending files over a network to printers that are not directly connected to your workstation. If printing problems do arise, the information in this section should help you correct them quickly.
The information applies to you only if you are printing from within an application or from the desktop.
If you are printing from the command line using lp, see "Using the lp Spooler" in the optional IRIX Advanced Site and Server Administration Guide for more troubleshooting information on lp. If you're using lpr, see the lpr man page for information on basic use.
This section covers two main topics:
"A Troubleshooting
Roadmap" gives you a brief overview of the printing process, plus
step-by-step information to isolate and resolve printing problems. You'll
get more out of this section if you also read "Understanding
the Printing Process", but, if you're anxious to resolve a problem
without reading through background information, start with this section.
"Understanding the Printing Process" describes the process in detail, outlines how and when the process may fail, and describes the troubleshooting tools that are available to you.
A successful printing process includes these four basic steps:
You must issue a print command and specify a printer that is set up
to work with your system.
Your system (the local system) must correctly process the request and send it to the system to which the printer is physically attached (the printing system).
Note: If the printer is physically attached to your system, the
local system is also the printing system; if the printer is attached to
another system on the network, that system is the remote, printing system.
The printing system must process the print request and send it to the
printer.
The printer must be in working order; if it's out of paper or toner, it cannot print.
See "Understanding the Printing Process" for a more detailed description of what the system does at each step.
The troubleshooting steps below show you how to determine which part of this process is failing. Be sure you know the Administrator's password; various steps require that you become the Administrator.
If you sent your job to the printer more than 30 minutes ago, send it
again. This way you can monitor its progress from the start.
Start the Printer Manager by choosing "Printer Manager" from
the System toolchest.
Find the icon for the printer to which you sent your job.
If the icon is there, double-click it to open it.
If you don't see the icon, that printer has not been set up to work with your system. See "Setting Up Printing Software".
Find your print job in the queue.
The entries in this window are jobs that have already reached the printer's queue.
If you see your job in the queue and the printer is attached to the
local system, skip ahead to step 6.
If you see your job in the queue and the printer is attached to a remote
system, go on to step 5.
If you don't see your job, see "Job Never Appears in the Local Queue".
Note: Your job may not appear in the queue immediately after you issue the print command; either it printed so quickly that the system didn't have time to display it in the queue, or there is a problem. If the printer did not print the job, wait several minutes before assuming it's not going to appear in the queue.
Physically go to the system to which the printer is connected. Its queue contains all print jobs that have actually reached the system. Find your print job in the remote queue.
Your job is labeled with your login name and is the same size as it is in the local queue. It does not have the same job number.
If you see your job in the remote queue, go on to step 6.
If you don't see your job, see "Job Never Appears in the Remote Queue".
Watch the queue of the printing system (the system to which the printer is attached).
If your job disappears from the queue, skip ahead to step 9.
If after several minutes no jobs disappear from the queue, go on to
step 7.
If all the jobs ahead of yours disappear, and jobs behind yours disappear while yours remains at the top of the queue, delete your job and try to print it again.
Make sure the printer is printing requests. Physically go to the system to which the printer is attached, open the printer's queue window, and choose "Printer Printing Your Queued Jobs" from the Queue menu.
If your job disappears from the queue, skip ahead to step 9.
If no jobs disappear from the queue, go on to step 8.
Check whether lpsched, the print spooler that controls the flow of jobs out of the queue, is running. On the printing system, open a shell window and type:
lpstat -r
Then press <Enter>.
If the lpsched spooler is running, you see this message:
scheduler is running
Go on to step 9.
If the lpsched spooler is not running, you see this message:
scheduler is not running
See "Checking and Restarting lpsched" to turn it on.
Check the physical state of the printer; for example:
Turn the printer off and on.
Make sure the paper or transparencies are properly loaded, there is
enough toner, and the printer isn't physically jammed.
Check all status lights and panels on the printer for error messages.
Make sure the cable is securely connected to the correct ports on both the system and the printer. If the cable appears frayed you may need to replace it.
Note: If you're not using a printer cable supplied by Silicon
Graphics, Inc., the pinouts may not match the workstation ports, even though
the cable seems to fit. Refer to the printer's owner's guide for details.
If you find a physical problem, correct it and try printing again.
If you find no physical problem and no jobs disappear from the queue,
the job's owner (possibly you) should cancel the job and try to print it
again. If the next job in the queue does not disappear, go on to step 10.
If you find no physical problem and your job disappears from the queue but does not print, see "Job Disappears from a Queue but Never Prints".
Remove all jobs from the queue and choose "Send Test Page" from the Printer menu to send a test page.
If the test page prints, try printing your job again.
If the test page doesn't print, contact your local support organization.
Use this section if the printer icon to which you sent your print job appears in the Printer Manager, but your job does not appear in the local queue. You should be looking at the printer's queue window.
Choose "Send Test Page" from the Printer menu to test the printer setup.
If the test job appears in the queue, try printing your job again. If
your job still doesn't appear, go on to step 2.
If the test job does not appear in the queue, make sure both "Printer Accepting Your Jobs" and "Printer Printing Your Queued Jobs" are chosen in the Queue menu. Send another test job. If it still doesn't appear, contact your local support organization.
Make sure you followed the correct steps to specify a particular printer for your job.
If you chose from a list of available printers and the job doesn't appear
in the queue, go on to step 3.
If you typed the printer name into a field, or if the application filled
in the field for you, make sure the name exactly matches that of a printer
that appears in the Printer Manager; then try printing again. Remember
that names are case-sensitive; "Printer1" is not the same as
"printer1". If it still doesn't appear, go on to step 3.
If you didn't explicitly specify a printer when you made the print request, either you or the application previously specified a default printer; the job may be in another printer's queue.
See the user's guide that came with the application to find out how it specifies a default printer and how you can change it. (For example, when you select a file and choose "Print" from the Selected toolchest or menu, the file is automatically sent to the printer that you specified as the default in the Printer Manager.) Change the default and try printing again. If it still doesn't appear, go on to step 3.
Make sure you gave the application all the printing information it needs.
Some applications (such as IRIS ShowcaseTM) have both a print command and a print dialogue box. If a dialogue box appeared and you didn't notice it, didn't fill it out correctly, or didn't confirm your information (that is, click an Accept or OK button), the job will not go to the queue.
If there is a dialogue box, fill it out completely, then try printing
again. If the job still doesn't appear in the queue, go on to step 4.
If there is no dialogue box, go on to step 4.
Open the console window and check for error messages.
Note: You must look in the console; error messages will not be reported to any other shell window.
If there are no error messages, contact your local support organization.
If a message states that you're out of disk space, then there isn't
enough space for the system to create a version of the file that is in
the correct format for the printer. Remove files or directories that you
no longer need and try to print your job again. You could also try just
printing a range of pages rather than the entire file.
If a message specific to the application from which you are printing appears, for example, a message stating that the application couldn't find a necessary file, refer to the documentation that came with the application.
Look in the file /var/spool/lp/log for error messages.
Use this section if your print job appears in your local queue, but does not appear in the queue when you view it on the system that's connected to the printer. You should be looking at the printer's queue window.
See if there is already a different job in the remote queue that was sent from your local queue (that is, a job that belongs to you or to another user on your local system).
If no jobs from your local queue appear in the remote queue, go on to
step 2.
If your local queue has already sent one job to the remote queue, it will not send another job to the remote queue until the first one prints. Wait until the first job disappears and, if your next job still does not appear in the remote queue, go on to step 2.
Make sure the local printer queue is sending print requests to the remote system.
Make sure "Printer Printing Your Queued Jobs" is chosen in the Queue menu. If no jobs from your local queue appear in the remote queue, go on to step 3.
Make sure the information about the remote system and remote printer that is shown in the printer's queue window is accurate.
If someone changed the name of the printer or physically moved the printer
and connected it to another workstation, your jobs cannot reach it. See
"Changing
the Setup of a Printer" to give the system the new information.
Then try printing again.
If the information about the remote system and printer is accurate, go on to step 4.
Check whether lpsched, the print spooler that controls the flow of jobs from the local queue to the remote system, is running. On your own system, open a shell window and type:
lpstat -r
Then press <Enter>.
If the lpsched spooler is running you see this message:
scheduler is running
Go on to step 5.
If the lpsched spooler is not running you see this message:
scheduler is not running
See "Checking and Restarting lpsched" to turn it on.
Test the network connection by opening a shell window and using the /usr/etc/ping command with the remote system's hostname. For example, if the remote hostname is mars, type:
/usr/etc/ping mars
Then press <Enter>. You see some messages that will repeat indefinitely; to stop the messages, press <Ctrl-C>. You see a summary of the connection. Look for these lines:
mars PING statistics <#>packets transmitted,<#> packets received,0% packet loss
If this line reports 0% packet loss, your connection to the remote system
is working. Go on to step 6.
If this line reports between 1% and 100% packet loss, your connection to the remote system is not stable. Physically go to the remote system to make sure both the printer and the system are turned on. If they were off, turn them on, and try to print again.
If they were already turned on, make sure the remote system is communicating with the network; use the /usr/etc/ping command on the remote system to try to reach a system on the network other than your system.
If the remote system can communicate with any other system on the network, your system may not be connected to the network properly. On your own system, try the /usr/etc/ping command with another hostname; also make sure your network cable is properly connected to your workstation. If you cannot communicate with any system over the network, or if a high percent packet loss continues, contact your network administrator. Either your network connection or the network itself has a problem.
Check the access permissions on the remote system by trying to copy a file to the remote system using the same login account that lpsched uses to copy over your job. For example, use jot to create a small text file named testit, then copy it to the remote system (mars) using the lp account; type:
su lp
rcp testit lp@mars:/usr/tmp
If you see no error messages, the file successfully reached the remote
system. Go on to step 7.
If you see an error message saying that the login was incorrect or that permissions were denied, contact the Administrator of the remote system; the Administrator needs to make changes to the lp account.
Choose "Send Test Page" from the Printer menu on your own system to test the printer setup.
If the test job appears in the remote queue, go on to step 8.
If the test job does not appear in the remote queue, physically go to the remote system, open the queue window for the printer, and turn off and on "Printer Printing Your Queued Jobs" and "Printer Accepting Your Jjobs" in the Queue menu. Go back to your own system and send another test job. If the test job appears, try to print your job again.
Physically go to the remote system and open the console window to check for error messages.
Note: You must look in the console on the remote system; error messages will not be reported to any other shell window.
If a message states that the system is out of disk space, then there
isn't enough space for the system to accept the file or to make a copy
of the file to print. Have the Administrator of the remote system remove
files or directories that are no longer needed and try to print your job
again.
If a message specific to the application from which you are printing
appears, for example, a message stating that the application couldn't find
a necessary file, refer to the documentation included with the application.
If there are no error messages, try to print your job again. If your job still does not appear in the remote queue, contact your local support organization.
Use this section if your print job disappears from a local or remote queue but the printer never prints it out.
Check your mail messages.
If the Administrator of the printing system deletes your job, you receive
a mail message to that effect. Contact the Administrator to make sure you
may try to print the job again.
If there is no such mail message, go on to step 2.
Check whether the printer is printing any jobs.
If the printer prints the next job in the queue, there is something
wrong with your particular job; go on to step 3.
If all jobs are disappearing from the queue but the printer does not print them, skip ahead to step 4.
Send the job again, and check whether the printer receives it.
Most printers have a status mechanism (a blinking light or digital message) that shows that the printer has received a job and is trying to print it.
If the status mechanism shows that it is trying to print your job but
never does, the job is too complex; the printer either gave up after a
specified period of time (that is, it "timed out"), or the printer
does not have enough memory to hold the job. If possible, break it up into
smaller jobs and try printing it again (for example, send only two pages
of a ten-page document). If it still doesn't print, go on to step 4.
If the status mechanism doesn't show that it is trying to print a job, the printer didn't receive data that it could understand. This means the initial processing that your application or other filter did to prepare the file for printing did not produce a file in the correct format for this printer. You may be missing some filtering software. Try printing the file on a different type of printer. For example, if you initially sent your job to a color image printer connected to a parallel port, now send it to a black and white PostScript printer connected to a serial port. If it still doesn't print, go on to step 4.
Remove all jobs from the queue on the printing system and choose "Send Test Page" from the Printer menu to send a test page.
If the test page prints, the printer is set up correctly, but cannot
print the types of files you are sending it. Contact your local support
organization.
If the test job disappears from the queue but doesn't print, contact your local support organization.
Use this section to check whether lpsched is running, and to restart it if necessary.
Check whether lpsched is running by typing:
lpstat -r
Then press <Enter>.
If the lpsched spooler is not running, you see this message:
scheduler is not running
Go to step 2 to turn it on.
If the lpsched spooler is running, you see this message:
scheduler is running
Turn on lpsched if it is not running.
Open a shell window on the system where it is not running, then log in as root by typing:
su
Then press <Enter>.
If a prompt for a password appears, type the password then press <Enter>.
If a prompt appears but the root account has no password, just press <Enter>.
Start lpsched by typing:
/etc/init.d/lp start
Then press <Enter>.
Log out of the root account by typing:
exit
Then press <Enter>.
Make sure lpsched is now running by typing:
lpstat -r
Then press <Enter>.
If the lpsched spooler is running, you see this message:
scheduler is running
Jobs that were not reaching a remote queue because lpsched was
not running on the local system should now reach that queue; jobs that
were not disappearing from the printing queue because lpsched was
not running on the printing system should now print out.
If you do not see this message, contact your local support organization.
This sequence of steps describes the process that your system uses to print files. The details (such as system name, application name, and job IDs) are only examples.
On your own system (saturn), you ask an application (IRIS Showcase)
to print a file (slide1), and explicitly or implicitly request a
particular printer (color-seiko).
Showcase (or another filter program) creates a new version of slide1
(a new file) that is in the correct format for color-seiko.
Showcase runs the lp command on the file on saturn. lp
assigns the file a job ID number (10), sends it to color-seiko's
queue, and alerts lpsched (the spooler that controls the flow of
jobs out of the queue) that the file (job #10) is ready to be printed.
The printer's queue displays job #10 in the local queue for color-seiko.
color-seiko is actually connected to another system on the network
(mars) where it is named seiko1. When job #10 reaches the
top of color-seiko's queue, lpsched copies it across the
network to the /usr/tmp directory on mars.
lp on mars makes a copy of job #10 in /var/spool/lp/request.
It then assigns it a new ID number (20) that doesn't conflict with other
IDs on mars, sends it to seiko1's queue, and alerts lpsched
on mars that job #20 is ready to print. The Printer Manager on mars
shows job #20 in seiko1's local queue; the Printer Manager on saturn
continues to show job #10 in color-seiko's queue.
When job #20 reaches the top of the queue, lpsched sends the
job over a cable to seiko1.
seiko1 receives job #20 and prints out slide1 on paper
or a transparency.
Job #10 disappears from color-seiko's queue; job #20 disappears from seiko1's local queue. lpsched sends the next job in color-seiko's local queue to mars.
This section shows how the process may fail at each step shown in "Understanding the Printing Process"; it does not describe how to correct the failure. See "A Troubleshooting Roadmap" for a step-by-step approach for isolating and correcting failures in the printing process.
When you ask an application to print a file on a certain printer:
The file may go to a printer other than the one you expect because a
hidden default is set.
You may specify a printer that's not currently set up on your system.
You may not actually complete the print request.
When the application or filter tries to create a new version of the file:
There may not be enough memory or disk space in the system for the new
file. If this is the problem, you see an error message in the console window.
The new file it creates may not be in the correct format for the printer (usually due to missing filter software). You will not find out that this has happened until the printer fails to print it. An error message appears in the /var/spool/lp/log file.
When the application runs lp on the file:
The printer may not be allowing new jobs to enter its queue, that is,
"Printer Accepting Your Jobs" is not chosen in the printer's
Queue menu.
If lp tries to make a copy of the file in /var/spool/lp/request,
there may not be enough memory or disk space in the system for the new
file. If this is the problem, you see an error message in the console window.
lp may not be able to find the printer you specified. If you
typed in a printer name that does not exist, lp cannot submit your
job to that printer's queue.
The permissions on the file may not be set up to allow others to read it; in this case lp cannot process it. If this is the problem, you see a message in the console window saying permissions were denied.
When lpsched tries to copy the file to the remote system:
If lpsched is not running, it cannot direct the file to a printer
or remote system. Typing lpstat -r determines whether lpsched
is running.
The remote queue may already contain a job that came from your local
queue. lpsched on your system waits until the job that is already
in the remote queue disappears from that queue before it sends the next
job.
The printer may not be allowing jobs to exit from its queue, that is,
"Printer Printing Your Queued Jobs" is not chosen in the printer's
Queue menu.
The network may be down.
Your system may not be communicating with the network; for example,
your networking software is not working or your network cable is loose.
The remote system may not be communicating with the network; for example,
it may be turned off.
The remote system may not allow your system to use the printer. See
the section on registering network printers in the optional IRIX Advanced
Site and Server Administration Guide for information on using the addclient
command.
The remote system may not have enough disk space to accept the file.
When lp on the remote system tries to process the file:
When lp tries to make a copy of the file in /var/spool/lp/request,
there may not be enough memory or disk space in the remote system for the
new file.
The remote printer may not be allowing new jobs to enter its queue,
that is, "Printer Accepting Your Jobs" is not chosen in the printer's
Queue menu.
The printer on the remote system may be gone or renamed. For example, if someone changed the name of seiko1 to seiko2, lp on the remote system cannot find seiko1. lp does not report this back to your system, so your job remains in the local queue as if it were printing, but never appears in the remote queue. lp does record the problem in the /var/spool/lp/log file on the remote system.
When lpsched sends the job over the cable to the printer:
If lpsched is not running, the file will never be directed to
a printer. Use the lpstat -r command on the remote (printing) system
to check lpsched.
The printer may not be allowing jobs to exit from its queue, that is,
"Printer Printing Your Queued Jobs" is not chosen in the printer's
Queue menu on the remote (printing) system.
The cable may be loose or disconnected.
The cable may be broken or frayed.
The cable may not have the correct pinouts to match the printer or the
system.
The printer may be turned off.
When the printer receives the job and tries to print it:
The printer may be jammed or out of supplies such as paper or toner.
The printer may not have enough memory to print a complex job. In this
case, the printer's status mechanism shows it is trying to print, but then
the printer gives up after a specified period of time, removes the job
from the queue, and prints nothing.
The printer may not understand the format of the job because the application or filter did not convert the file correctly. In this case, the printer's status mechanism never shows that it is trying to print, and the printer removes the job from the queue but never prints it.
When jobs disappear from the queue:
Jobs may disappear from the queue but never actually print as described
above.
Jobs may never disappear from the queue if the physical printer is not
working correctly.
If jobs ahead of yours in the queue disappear, then jobs behind yours disappear while yours remains at the top of the queue, there is something wrong with your job; cancel it and try to print it again.
When you troubleshoot printing problems using "A Troubleshooting Roadmap," you use a number of different tools and techniques. This section summarizes the tools, and suggests other sources of information on isolating and correcting problems.
This section shows you how to diagnose and fix these common problems:
The print request never reaches the printer's queue.
The print request reaches the queue, but never disappears from the queue
because it cannot reach the remote host (printing system).
The print request reaches the printing system and disappears from the queue, but the printer either never prints it or prints something unexpected.
If the print request never reaches the printer's queue (if you don't see the request when you type lpq), follow these steps:
Make sure you entered the print command correctly.
If you set up the printer you are trying to use as the default, use this format:
lprfilename
If you did not set up the printer you are trying to use as the default, use this format:
lpr -Pprintername filename
Check for error messages.
In the window from which you issued the lpr command, look for this message:
lpq:printernameunknown
This tells you that the printer name you specified (either by editing
.cshrc or .profile, by setting the default with a command
line, or by using the -P option) does not match a printer name in
the /etc/printcap file. Check the print request you typed in step
1 and the edits you made to /etc/printcap for typing errors.
Choose "View System Log" from the System toolchest, and look for lpd or lpr errors.
Send a simple file to the printer, such as /etc/group.
If this file reaches the queue, lpr is working correctly, but
there is something wrong with the file you originally sent.
If it does not reach the queue, type:
/usr/etc/lpc status
Then press <Enter>. You should see messages like these:
printername:
queuing is enabled printing is enabled jobs in queue no daemon present
Note: The no daemon present line always appears; this
is a known bug.
If the queue or printing is not enabled, enable these functions by typing:
/usr/etc/lpc up all
Then press <Enter>.
If it still doesn't reach the queue, contact your local support provider.
If the print request reaches the queue, but never disappears from the queue because it cannot reach the remote host (printing system), follow these steps:
Check for error messages:
Open the window from which you issued the lpr command.
Look for this message:
Waiting for remote queue to be enabled
If you see this message, ask the Administrator of the printing system
to add your system's hostname to the /etc/hosts.equiv file on the
printing system and your system's hostname and IP address to the /etc/hosts
file.
Look for this message:
lpr: connection refused jobs queued but cannot start daemon
If you see this message, stop the lpr daemon (lpd) by typing:
/etc/init.d/bsdlpr stop
Then press <Enter>.
Restart the daemon by typing:
/etc/init.d/bsdlpr start
Then press <Enter>. Try printing the job again.
Look for this message:
connection tohostnameis down
Your system cannot reach the printing system. Follow the instructions in step 2 to check the network connection.
Make sure you can access the printing system.
Choose "Hosts" from the Search For rollover menu in the Find
toolchest.
In the field next to whose name contains string, type the name of a system that you know is running and is connected to the network; then click the Search button.
If the system appears in the Search window, your network connection is working.
If the system does not appear, try another system. If it still does not appear, see "Troubleshooting Network Errors".
Ask the Administrator of the printing system to verify that your system's hostname is in the /etc/hosts.equiv file on the printing system and that your system's hostname and IP address are in the /etc/hosts file. Also ask the Administrator to verify that the printer is enabled and ready to print requests. When this is done, try printing again.
If the job still doesn't reach the printing system, follow the instructions in "Testing the Network Connection" for a more comprehensive test.
If the print request reaches the printing system and disappears from the queue, but the printer either never prints it or prints something unexpected, follow these steps:
Log in as root through a shell window.
Choose "Unix Shell" from the Desktop toolchest.
Position your cursor within the new window and type:
login root
Then press <Enter>.
If a prompt for a password appears, type the password then press <Enter>. If a prompt appears but the root account has no password, just press <Enter>.
Send a test job to check whether lpr on your system is spooling jobs correctly.
Cancel all jobs in printer color's queue and stop it by typing:
/usr/etc/lpc stop color
Then press <Enter>.
Send /etc/group as a test file by typing:
lpr /etc/group
Then press <Enter>.
Change directories so you are in your spool directory, for example, /var/spool/lpd, and list its contents by typing:
cd /var/spool/lpd; ls -l
Then press <Enter>. You see a listing similar to this:
-rw-rw---- 1 joe lp 25 Mar 17 14:02 cfA117mars -rw-rw---- 1 joe lp 69 Mar 17 14:02 dfA117mars -rwxr----- 1 joe lp 00 Mar 17 14:02 lock -rw-rw-r-- 1 joe lp 12 Mar 17 14:02 status
Compare the copy of the file to print (the one that starts with df - in this example, it is dfA117mars) with the test file you sent (/etc/group) by typing:
diff dfA117mars /etc/group
Then press <Enter>. If the system prompt returns and you see no listing of differences, lpr is working correctly on your system. Go on to step 3.
If the system lists differences, lpr is not working correctly on your system. Repeat the steps in "Setting Up lpr" to make sure you set up lpr correctly.
Once you know that lpr is working correctly on your system, you can assume that there is a problem with the printing system. Contact the Administrator of the printing system; this person will have to perform some of the steps in the rest of this troubleshooting procedure.
On the printing system, the Administrator should log in as root, then cancel all jobs in printer colorful's queue and stop the printer by typing:
/usr/etc/lpc stop colorful
Then press <Enter>.
On your system, start printer color by typing:
/usr/etc/lpc start color
Then press <Enter>.
On your system, send /etc/group as a test file by typing:
lpr /etc/group
Then press <Enter>.
On the printing system, the Administrator should change directories to the spool directory, for example, /var/spool/lpd, and list its contents by typing:
cd /var/spool/lpd; ls -l
Then press <Enter>.
The listing should be similar to this:
-rw-r----x 1 joe lp 25 Mar 17 14:02 .seq -rw-rw---- 1 joe lp 25 Mar 17 14:02 cfA117mars -rw-rw---- 1 joe lp 69 Mar 17 14:02 dfA117mars -rwxr----- 1 joe lp 00 Mar 17 14:02 lock -rw-rw-r-- 1 joe lp 12 Mar 17 14:02 status
On the printing system the Administrator should compare the copy of
the file to print (the one that starts with df - in this example,
it is dfA117mars) with the test file you sent
(/etc/group) by typing:
diff dfA117mars /etc/group
Then press <Enter>. If the system prompt returns and there is no listing of differences, lpr is working correctly on the printing system. Go on to step 4.
If the system lists differences, lpr is not working correctly on the printing system. The Administrator of the system should check the printer setup.
Once you know lpr is working correctly on the printing system, the Administrator should restart the printer (named colorful) on that system by typing:
/usr/etc/lpc start colorful
Then press <Enter>.
If the test job (/etc/group) prints, you should be able to print
other files. If you cannot print a particular file, there is a problem
with the file, for example, it may be too complex or in a format that the
printing filter on the printing system cannot interpret.
If the test job doesn't print, the Administrator of the printing system should check for physical problems, such as disconnected cables.
For troubleshooting information, see "Troubleshooting Software Installation."
If any of your physical devices are not working properly, run the appropriate confidence test. Follow these steps:
Choose "Run Confidence Tests" from the System toolchest.
Double-click the device that you want to test. On-screen instructions
guide you through the test.
If a device is faulty, contact your local service organization.
|
|
Copyright © 1997, Silicon Graphics, Inc. All Rights Reserved. Trademark Information