This chapter contains detailed troubleshooting information on these topics:
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, you can use the “Set Filesystem Space Monitoring” guide. See “Set Filesystem Space Monitoring ” in Chapter 6 for more information. Also take a look at the System Alert customization panel, which you can find in the toolchest: Desktop > Customize > System Alerts.
To get more detail on a particular message, you can view the System Log. Open the System Manager (choose “System Manager” from the System toolchest), select the System Performance category, and then click “View the System Log.”
The Software Manager has several built-in troubleshooting tools:
Informative dialogs provide status information and warnings.
The Conflicts window reports installation conflicts and helps you resolve them; see “Resolving Installation or Removal Conflicts”.
The Status area and Log pane provide information throughout an installation and/or removal session; see “Viewing Status and Log Information”.
The system file /var/inst/INSTLOG contains all status and error messages from each Software Manager and Inst session.
Click a problem for information on solving it.
For comprehensive, advanced troubleshooting information, see IRIX Admin: Software Installation and Licensing .
When you are customizing an installation, Software Manager monitors your installation and removal choices as you make them. When it detects that you have selected a combination of software that cannot be safely installed or removed, it alerts you by making the Conflicts button active. When you click the Conflicts button, the Conflicts window appears in which you can resolve the problem. In an automatic installation, the Conflicts button does not become active; Software Manager automatically displays the Conflicts window.
 | Note: In many cases, as you customize your installation, you can create and resolve conflicts as you click the Install and Remove check boxes. You may want to wait to view the Conflicts window until you have made all your selections. |
Click a topic for more information:
If you need to resolve conflicts by opening a CD, the installation selections you already made may be altered on the CD you open. Review what is selected on the CD and deselect or reselect as needed.
If a conflict gives you the option of deselecting a product with “eoe” or “Execution Environment” in the product name, do not choose to deselect the product. The operating system needs “eoe” products in order to function properly. Exception: You do not have to install “eoe” products that are man (manual) pages or relnotes (release notes).
If you deselected subsystems, conflicts may be generated by remaining patches that go with the deselected subsystems. However, because such patches go with subsystems you are not installing, you do not need to install them.
Conflicts usually arise when one of the following occurs:
Your selections do not include one or more products that are required for the operating system to run. This can happen when you do not select a required product for installation, or when you select a required, installed product for removal.
The system is missing one or more prerequisite products. This can happen when a prerequisite product is not currently installed, when you select a product for installation and then select a prerequisite product for removal, or when you select a product for removal that is a prerequisite product for other products that are already installed.
You select incompatible products. This can happen when you choose to install a version of a product that cannot work on (is incompatible with) the current version of the operating system software, or when you choose to install two versions of the same product.
You select a product for installation that is an older version of a product that is already installed.
You select a patch upgrade product (a product that corrects problems with a base product) for installation, and select its base product for removal.
The Conflicts window describes each conflict (see also “Understanding Types of Conflicts”), and gives you several options for resolving it; you choose only one of these options. If software that you need to install to resolve a conflict is not available, the option is shown, but is not active; see “Switching Distributions to Resolve a Conflict”.
Note the total number of conflicts. Often when you resolve one conflict, it either resolves or creates other conflicts. As you proceed, note how the total number of conflicts listed at the top of the window changes.
Read the description of each conflict and its resolution options, then choose an option using these guidelines:
When you have selected an optional product that is incompatible with the rest of the operating system, do not install it.
When you have selected incompatible products, choose to install the newer version of a product.
When the system is missing one or more prerequisite products or subsystems, choose to install the prerequisites.
If the prerequisite is not available (that is, it is not located on the CD or in the distribution directory that's specified in the Available Software field) the option is shown but is not active; to install the software, see “Switching Distributions to Resolve a Conflict”.
When you have resolved all conflicts, the Conflicts window closes automatically.
In the Software Manager window, the Start button should now be active; click it to start the software installation or removal.
When you want to resolve a conflict by installing a product that is not available (that is, it is not located on the CD or in the distribution directory that's specified in the Available Software field), follow these steps:
In the Conflicts window, choose “Open Additional Distribution” from the File menu.
The “Open Additional Distribution” dialog box appears and prompts you to enter another distribution.
Locate the additional distribution from which you want to install.
If you're installing a distribution located on a CD, remove the existing CD from your drive and place the new CD into the drive.
If you are installing from a CD drive connected to a remote system, go to that system, remove the CD, and place the new CD into the drive.
If you're installing from a distribution directory located on a remote system, get that system's hostname and the full pathname of the directory from your network administrator.
In the “Open Additional Distribution” window, select a distribution using one of these methods.
Select the name of a distribution that appears in the list of available ones and click the Add button.
If the software is in a directory that is on another system, click in the Distribution field, type the remote system's name, a colon (:), and the full pathname of the directory, then click the Add button.
Click the Browse button to open a file browsing window, then navigate through the system's directories to locate the distribution directory. After you locate the distribution you want, select it and click the Add button.
Both the Status area and the Log pane provide information throughout an installation and/or removal session.
The Status area provides high-level, easy-to-understand information and warnings. To view it, choose “Status/Disk Space” from the Panes menu.
The Log pane provides very detailed information, which is especially useful when you encounter problems (other than installation conflicts) during an installation. To view it, choose “Log” from the Panes menu.
The system cannot find the software when any of the following occurs:
There is no CD in a drive that you specified.
The remote CD drive that you specified is not enabled for remote software installations. Contact the Administrator of that system to check whether this is the case. (See also “Allowing Remote Users to Install Software From Your CD Drive” in Chapter 3.)
Your system cannot contact the system on the network that has the software. See “Troubleshooting General Network Errors”.
You entered an incorrect distribution directory name.
This typically happens when you are installing from a remote CD drive, and the drive is not accessible from (is not mounted at) the /CDROM directory.
Choose “Shared Resources” from the Desktop toolchest and then choose “On a Remote Workstation” from the rollover menu. Type the name of the remote workstation to which the CD drive is connected. A list of the available devices appears. Drag the /CDROM folder icon from the window into the Available Software drop pocket in the Software Manager.
Also, be sure to complete the full pathname with /dist, which is the name of the directory on the CD in which the software is stored. For example, the full pathname for new software on a CD whose pathname is /drives/cdrom on a system named mars is mars:/drives/cdrom/dist.
If an installation ends before it is complete (for example, if the Software Manager unexpectedly quits), you can attempt to finish the installation session by following these steps:
If the Software Manager window is still available, choose “Exit” from the File menu.
Restart the Software Manager by choosing Software Manager from the System toolchest.
Before the main Software Manager window appears, you see a notifier that describes the location of the software, lists products that were selected for installation but were not installed, and gives you several choices. Review these options:
Retry the previous installation. This is the default selection; the Software Manager window appears, and the Software Manager attempts to complete the installation.
Restore the previous installation session. This starts up Software Manager so you can review the installed and uninstalled software. You can then either quit Software Manager without completing the installation, or resume the installation by clicking the Start button.
Ignore the previous installation session. This starts up Software Manager with no history of the previous installation.
Note: When you choose to ignore the session, the Software Manager saves the session information in the file /var/inst/.checkpoint.O. If you ever want to complete the session, choose “Load Selections” from the File menu, and enter this filename.
Choose an option, then click the OK button.
If you chose to resume or view the installation session and you see an error message, see “Resolving Errors During a Resumed Installation Session”.
If the installation of a new operating system ends before it is complete (either because you clicked Stop or because the system encountered errors), the Inst> prompt appears. You must now use Inst commands to resume, quit, or troubleshoot the installation. For more information, see IRIX Admin: Software Installation and Licensing .
When you resume an installation session that ended unexpectedly (before it was complete), you may encounter these error messages:
The distribution pathname does not exist. The distribution that was in place for the initial installation session is no longer there. This could happen when a network administrator removes a distribution directory.
Invalid product product in selections file. The distribution directory or CD still exists, but it contains a different set of products from that of the initial installation. This typically happens when the original CD was removed and replaced with another one.
Conflicts must be resolved. Conflicts that didn't exist during the initial installation now exist. If the Conflicts window is not displayed, click the Conflicts button to resolve them, and see “Resolving Installation or Removal Conflicts”.
Installation requires too much space. The system no longer has enough disk space to complete the installation. Select fewer products or subsystems to install, or remove other data from your disk; see “Freeing Disk Space” in Chapter 6 or “Not Enough Disk Space for Installation” for more information.
If you need to free up disk space to perform an installation, you can use one of these methods:
Remove products by following these steps:
Choose “Save Selections” from the File menu to save your current selections in a file.
Choose “Unmark All” from the Selected menu to clear all current selections.
Click Manage Installed Software.
Select products for removal and click Start. (See “Removing a Product” in Chapter 2 for more information about removing products.)
When the products have been removed, choose “Load Selections” from the File menu to restore your original selections.
Relocate products by following these steps:
Choose “Save Selections” from the File menu to save your current selections in a file.
Choose “Unmark All” from the Selected menu to clear all current selections.
Click Manage Installed Software.
Choose “Relocate Products” from the File menu.
If this item is not available in the menu, your system does not contain any products that can be relocated.
In the “Relocate Products” window, look for products that are located on filesystems with small amounts of free disk space.
Look at the “Filesystems” column in the window for information.
Select the products you want to relocate (you can select more than one) and then click the Apply button.
Depending on the size of the products being relocated, the operation may take a while.
If you have problems ejecting a CD from a drive, try one of the following:
Select the CDROM icon on the desktop and use the right mouse button to choose “Eject CDROM” from the pop-up menu.
Eject the CD manually using the button on the drive.
Type eject /CDROM in a shell window.
Use the methods described in this section for basic troubleshooting.
Run the UNIX command /usr/sbin/lmdiag -c /var/flexlm/license.dat or /usr/sbin/lmdiag -c /var/flexlm/license_serverhost.dat. to analyze the licenses in the license files. If you get an error message that says the HOSTID is incorrect, then:
For a Nodelocked license, run the UNIX command /etc/sysinfo -s. If the result does not match the HOSTID string for that product in the license file, this is the problem.
For a Floating license, on the server system, run the UNIX command /etc/sysinfo -s. Compare the results with the second argument on the SERVER line, which corresponds to the product in question. If the two numbers are not identical, this is the problem.
Conditions that might cause the /etc/sysinfo -s results and the HOSTID to be different, include (1) the license may be for a system different from the one it is installed on, (2) the HOSTID may have been entered incorrectly, or (3) the HOSTID on the system may have changed (replacing the system board or I/O board can change the HOSTID).
For trouble with a Floating FLEXlm license, configure the lmgrd daemon on the server to send its output to a log file by adding:
-c /var/flexlm/license_servername.dat -l /var/adm/flexlm.log
to the /etc/config/lmgrd.options file, where /var/adm/flexlm.log is the log file. Note that -l is a lowercase letter l, not a number 1 (one). In a UNIX shell, type:
/etc/init.d/flexlm stop; /etc/init.d/flexlm start
Look at the log file for error messages.
If the application program (or lmstat) can't connect to the license server, one of several things may be wrong:
The license server may be down, or there may be a network problem. Verify that the client system can communicate with the server. In a UNIX shell on the server, type:
setenv LM_LICENSE_FILE /var/flexlm/license_servername.dat
and then type:
/usr/sbin/lmstat -a
to verify the vendor daemon is running. In a UNIX shell on the client system, enter lmstat -a to check if the system can contact the vendor daemon on the server. Then, from the client system, enter the command telnet hostname portnumber, where hostname and portnumber match the SERVER line in the license file.
The Silicon Graphics vendor daemon may not be running. On the server, verify that it is running by typing the UNIX command ps -ef | grep sgifd | grep -v grep. If nothing is returned, then the vendor daemon is not running.
The application may not be looking at the expected license file. The default license file for Silicon Graphics products is /var/flexlm/license.dat. Verify the contents of /var/flexlm/licensefile.db to see what files are being looked at. Type:
more /var/flexlm/licensefile.db
to view contents lists of all expected license files.
If a warning message appears stating that the license expires in an incorrect number of days, remove or comment out temporary or evaluation license(s) in the /var/flexlm/license.dat file for this product.
The License Password may have been typed incorrectly. Check that the letters l and O were not typed in place of a numeral 1 (one) or 0 (zero).
Run the date command by typing date. Make sure the date is not earlier than the Start Date or later than the Expiration Date listed on the license information sheet.
For more information on troubleshooting, refer to Appendix B of the FLEXlm End User Manual. This guide is located in the IRIS InSight Library, which you can find by selecting “Online Books” from the Help toolchest.
If you see an error message such as “Unable to find a license” or “Unable to find a license server,” use the methods described in this section to check the installation.
If a warning message appears stating that the license expires in an incorrect number of days, remove or comment out temporary or evaluation license(s) in the /var/netls/nodelock file for this product.
The License Password or Vendor ID may have been typed incorrectly. Check that the letters l and O were not typed in place of a 1 (one) or 0 (zero).
The system ID may be different from the system ID that the license was issued for. To verify that the numbers are the same, type:
/etc/sysinfo -s
The number that appears should be the same number as the System ID on the license information sheet. If the System ID field on the license sheet is "Any," then the system ID is not the problem.
The license you are entering may not be the correct type. Check the License Type on the license information sheet.
Run the date command by typing date. Make sure the date is not earlier than the Start Date or later than the Expiration Date listed on the license information sheet.
If you are installing a Concurrent access license, check the SYSLOG file for error messages that indicate what the problem is. Check it by typing
tail /usr/adm/SYSLOG
or select “View System Log” from the System toolchest.
Look at the last few lines of output.
If the server does not show up in ls_admin, or if ls_admin returns the error Unable to locate any Network License server, restart the daemons with these commands:
/etc/init.d/netls stop /etc/init.d/nck stop /etc/init.d/nck start /etc/init.d/netls start
If you get the error message Password contains invalid characters while entering information into ls_admin, there may be an invisible carriage return at the end of the line. Position the cursor at the end of the password field and use the Backspace key to delete invisible characters.
When you insert a CD, tape, or disk (including floppy, floptical, SyQuest, Zip, Jaz, or PCCard disk) 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, see “Format Removable Media” in Chapter 3.
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 filenames are too long or do not conform to the DOS naming conventions. DOS filenames can contain no more than eight characters, a period (.), and a three-character extension (for example, projects.exe uses the maximum filename length).
If you cannot share resources, or cannot drag shared resources from other systems onto your own desktop, either the optional NFS software is not installed or is not turned on, or an important NFS utility called autofs (or automount) is not turned on.
To turn on NFS, open the System Manager window if it's not already open (choose “System Manager” from the System toolchest). Select the Network and Connectivity category and then click “Set up and Start NFS” in the right-hand column. The guide appears and leads you through the necessary steps, including the step necessary for enabling autofs (or automount).
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 “Open Unix Shell” from the Desktop toolchest.
Use the /usr/etc/ping command with the name of a remote host that appears in the Host Manager (see “Host Manager” in Chapter 5 for more information). 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 repeat indefinitely; to stop them, press Ctrl+C. Your connection is working.
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.
Note: If you don't have a console window, choose System > Utilities > Start New Console from the toolchest. 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.
Make sure TCP/IP is turned on, and, if your system is on an NIS network, make sure NIS is turned on and the correct NIS domain name is entered.
Use the “Set Up and Start Networking” guide to make sure TCP/IP is turned on. See “Set Up and Start Networking” in Chapter 5 for more information.
Use the “Set Up and Start NIS” guide to make sure NIS is turned on and to verify that your NIS domain name is correct. See “Set Up and Start NIS” in Chapter 5 for more information.
If these guides confirm that your settings are correct and you still can't connect to the network, contact your network administrator to report that your network connection is not working correctly.
Once you've used the Printer Manager to set up the printers that you want to access, printing files is usually very straightforward — you print a file through an application, 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.
If you are printing from the command line using lp, see the lp(1) reference (man) page. If you're using lpr, see the lpr(1) reference (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 “Adding, Removing, and Sharing Printers” in Chapter 3.
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.
If lpsched is not running, the Printer Manager displays an error dialog. See “Checking and Restarting lpsched” for instructions about turning it on.
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 the physical state of the printer:
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 9.
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 Showcase) have both a print command and a print dialog box. If a dialog 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 dialog 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 dialog box, go on to Step 4.
Open the console window and check for error messages.
Note: You must look in the console; error messages are not reported to any other shell window. 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 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.
You may want to type the command tail -f /var/spool/lp/log in a shell window and then run the printer test again (go to Step 1 of this section). This command lets you see error messages as they occur.
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 queue window on the remote printer hosts.
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 does 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 “Adding, Removing, and Sharing Printers” in Chapter 3 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.
If lpsched is not running, the Printer Manager displays an error dialog. See “Checking and Restarting lpsched” for instructions about turning 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.
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 can make changes to the lp account using the “Share Printers” guide available in the System Manager.
Choose “Send Test Page” from the Printer menu in the Printer Manager on your own system to test the printer setup.
If the test job appears in the remote queue, go on to Step 7.
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 Jobs” 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 are not 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.
Look in the file /var/spool/lp/log for error messages.
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 the printer 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 another 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 disappearing from the printing queue because lpsched was not running on the printing system should now print out.
If lpsched fails to start and you see the file /var/spool/lp/core, check if it is a new lpsched core file.
In a shell window, type
mv /var/spool/lp/request /var/spool/lp/request.broken
Start lpsched again.
If lpsched works now, a corrupted file in request.broken was causing lpsched to crash.
If you do not see the “scheduler is running” 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).
IRIS Showcase (or another filter program) creates a new version of slide1 (a new file) that is in the correct format for color-seiko.
IRIS 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 lpsched on mars.
lpsched on mars assigns your job a new ID number (20) that doesn't conflict with other IDs on mars, and puts it in seiko1's queue. 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 do 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.
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. The system displays an error dialog; see “Checking and Restarting lpsched” for more information.
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 PrintStatus 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. The remote system can use the “Share a Printer” guide to give you access to the printer; see “Adding, Removing, and Sharing Printers” in Chapter 3.
The remote system may not have enough disk space to accept the file.
If lpsched is not running, the job did not go over the cable. Use the Printer Manager on the remote system to check lpsched.
When lpsched on the remote system tries to process the file:
When lpsched 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 PrintStatus Queue menu.
The printer on the remote system may be gone or renamed. For example, if someone changed the name of seiko1 to seiko2, lpsched 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 local system.
When lpsched sends the job over the cable to the printer:
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.
| “Send Test Page” | |
This choice appears in the Printer menu in the Printer Manager window and in each individual printer's PrintStatus Queue window. When you choose “Send Test Page,” you run the lp command on a sample file that is already in the correct format for that printer; in other words, you bypass Steps 1 and 2 of the printing process described in “Understanding the Printing Process”. | |
| lpstat | |
This IRIX command provides an alternate view of the queues that PrintStatus displays; it also reports whether lpsched is running. To see a full lpstat listing that includes queues for every printer on the system plus the status of lpsched, type lpstat -t | |
| /var/spool/lp/log | |
| |
| /var/spool/lp/oldlog | |
These files contain a history of all printing activity and errors. The messages are often difficult to understand, but you may find some useful error information that you can use for troubleshooting. For example, a “login incorrect” message that has a timestamp near a time when your job could not reach a remote queue may make you suspect that there is a password on the lp account on the remote system. | |
| /etc/init.d/lp start | |
This IRIX command restarts the scheduler, lpsched. | |
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:
lpr filename
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:printername unknown
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 the file 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 may appear; 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 the file 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 lpq 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 or the hosts.lpd 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 to hostname is 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 by using the /usr/etc/ping command with the printing system's hostname.
For example, if the printing system's hostname is mars, open a shell window and type:
/usr/etc/ping mars
Then press Enter. You see some messages that 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 system is working.
If this line reports between 1% and 100% packet loss, your connection to the system is not stable. Try using the same command with another hostname. If the line still reports a packet loss, 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 or the hosts.lpd 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” in Chapter 5 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 “Open 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” in Chapter 3 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, who can 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.
The troubleshooting information in this section covers many common error conditions. If you need more-detailed information, see the ppp(1M) reference (man) page.
This section shows you how to use a shell window and issue direct PPP commands to troubleshoot efficiently.
Make sure that all physical connections are solid and that the NT1 device is powered on. If you had to solidify a connection or power on the NT1 device, restart the system and try using ISDN again.
Open the ISDN Manager.
Select the Network and Connectivity category in the left-hand column of the System Manager window. In the right-hand column, click ISDN Manager.
In the ISDN Manager window, click the Confidence Test button to start the test.
If there is a problem, one or more error messages appear. If the notifier reports a problem, follow the instructions that the confidence test gives you for correcting it.
To see startup status messages for testing purposes, type
ppp -r connectionname -d
in a shell window.
This section lists various error messages that you may encounter during your initial setup of ISDN. Typically you see these messages after trying to connect to a remote system for the first time by typing ppp -r connectionname -d in a shell window, The messages generally appear in your shell window, although some of them appear in the /var/adm/SYSLOG file.
To obtain information on error or status messages, follow these steps:
Open another shell window and in the new window type
isdnstat
When you place the call in the next step, isdnstat reports on the progress of the call. For more details, see the isdnstat(1M) reference (man) page. To stop isdnstat from running, type:
q
In the shell window in which you're logged in as root, place the call and request additional information from PPP by typing
ppp -r connectionname -d
You do this in the shell window because the debug messages are displayed in the shell window as
ppp [xxx] connectionname:errormessage
The window in which you started isdnstat shows the progress of ISDN, and the window in which you typed the ppp command gives you information about PPP.
You can request more information by adding additional -d flags to the ppp command line, but this introduces security problems. See the ppp(1M) reference (man) page for details.
This section covers these error conditions:
Unknown switchtype "switchtype"
This message indicates a problem in ISDN's configuration.
To verify that the switch software type is correct, select Network and Connectivity in the left-hand column of the System Manager window. In the right-hand column, select “Set Up ISDN.”
ppp[348] connectionname: fatal error “LOGIN FAILED” on try #2
ppp[348] connectionname: giving up for now
This message may appear immediately (within three seconds) after you try to make the connection, or may appear after several more seconds.
If you see the message immediately, your system cannot access the ISDN line through your NT1 device, typically because the NT1 is powered off or the telephone line is unplugged. Check that all connections are solid and that the NT1 is powered on, then follow these steps:
Open a shell window, log in as root, then type
/etc/init.d/isdnd stop /etc/killall ppp /etc/init.d/isdnd start
Wait 30 seconds, then try again, requesting more error or status information, by typing
ppp -r connectionname -d
If you see the same error message, there may be a problem with the telephone company's switching software. Contact the telephone company to report the problem.
If you see the Login Failed message after several seconds, there is a different problem; for example, the remote system may be down or its ISDN connection may already be in use. For more information, follow these steps:
Open another shell window and in the new window type
isdnstat
When you place the call in the next step, isdnstat reports on the progress of the call. For more details, see the isdnstat(1M) reference (man) page. To stop isdnstat from running, type
q
In the shell window in which you're logged in as root, place the call and request additional information from PPP by typing
ppp -r connectionname -d
The window in which you started isdnstat shows the progress of ISDN, and the window in which you typed the ppp command gives you information about PPP.
ppp[434] connectionname: fatal error “SYSTEM NOT IN Systems FILE” on try #2
ppp[348] connectionname: giving up for now |
The above message means that there is a problem with the outgoing connection that you added.
Use the “Modify an Outgoing PPP Connection” guide to correct any errors with the connection.
Select the Network and Connectivity category in the left-hand column of the System Manager window and click PPP Manager.
Select the connection that isn't working and click the Modify button.
The “Modify an Outgoing PPP Connection” guide appears.
Check your settings. In particular, be sure of the following:
If the telephone number is outside your area code, the telephone number entry must exactly match what you would dial on a telephone to call the number. For example, for connections between two U.S. locations that are in different area codes, the entry must consist of 11 digits (1 + the area code + a 7-digit phone number).
The word CONNECTED should appear at the end of each line.
The rate should be appropriate for your location (typically 56 within the United States, 64 elsewhere).
ppp[483] connectionname: failed to find entry labeled `mars' in /etc/ppp.conf -- assume defaults
ppp[483] connectionname: fatal error “LOGIN FAILED” on try #2 ppp[483] connectionname: giving up for now |
The message shown above means that there is a problem with adding a PPP connection.
Select the Network and Connectivity category in the left-hand column of the System Manager window and click “PPP Manager.”
Select the connection that isn't working and click the Modify button.
The “Modify an Outgoing PPP Connection” guide appears.
Check your settings.
Device Type ISDN wanted Requested Device Type Not Found Call Failed: NO DEVICES AVAILABLE |
One or more of the above messages indicates that the file /etc/uucp/Devices is either missing information or is corrupted.
Verify that the file contains these two lines:
ISDN isdn/modem_b1 - 38400 direct ISDN isdn/modem_b2 - 38400 direct |
If the lines are missing, add them to the file and save the changes. Then restart the connection: In the panel that appears when you double-click the icon of the connection you want to use (in the PPP Manager), click Open Connection.
This section lists various error conditions and messages that you may encounter when starting an ISDN connection that usually works. The messages may appear in your shell window or in the /var/adm/SYSLOG file.
For more informative error or status messages when trying to make a connection, follow these steps:
Open a shell window and in the new window type:
isdnstat
When you place the call in the next step, isdnstat reports on the progress of the call. For more details, see the isdnstat(1M) reference (man) page. To stop isdnstat from running, type
q
In another shell window in which you're logged in as root, place the call and request additional information from PPP by typing
ppp -r connectionname -d
The window in which you started isdnstat changes to show the progress of ISDN, and the window in which you typed the ppp command gives you information about PPP.
You can request more information by adding additional -d flags to the ppp command line, but this introduces security problems. See the ppp(1M) reference (man) page for details.
This section covers these error conditions:
ppp[348] connectionname: fatal error “LOGIN FAILED” on try #2
ppp[348] connectionname: giving up for now |
This message may appear immediately (within three seconds) after trying to make the connection, or may appear after several more seconds.
If you see the message immediately, your system cannot access the ISDN line through your NT1 device, typically because the NT1 is powered off or the telephone line is unplugged. Check that all connections are solid and that the NT1 is powered on, then follow these steps:
Open a shell window, log in as root, then type
/etc/init.d/isdnd stop /etc/killall ppp /etc/init.d/isdnd start
Wait 30 seconds, then try again, requesting more error or status information, by typing
ppp -r connectionname -d
If you see the same error message, there may be a problem with the telephone company's switching software. Report the problem to the telephone company.
If you see the Login Failed message after several seconds, there is a different problem; for example, the remote system may be down or its ISDN connection may already be in use. For more information, follow these steps:
Open a shell window, and in the new window type:
isdnstat
When you place the call in the next step, isdnstat reports on the progress of the call. For more details, see the isdnstat(1M) reference (man) page. To stop isdnstat from running, type
q
In another shell window in which you're logged in as root, place the call and request additional information from PPP by typing
ppp -r connectionname -d
The window in which you started isdnstat shows the progress of ISDN, and the window in which you typed the ppp command gives you information about PPP.
connectionname: Network is unreachable
The above message means that your system cannot determine the correct route to the remote system. To add a route to the remote system:
Select Network and Connectivity in the left-hand column of the System Manager window. In the right-hand column, click “Modify an Outgoing PPP Connection” and follow the directions.
On Page 9 of the guide, select Add Route.
Note: The add_route line establishes a static default route. If your Internet service provider or network administrator requires another type of routing (for example, if you have a routing daemon turned on), contact that person and describe your problem. See also the gated(1M) and routed(1M) reference (man) pages. Open another shell window and in the new window type:
isdnstat
When you actually place the call in the next step, isdnstat reports on the progress of the call. For more details, see the isdnstat(1M) reference (man) page. To stop isdnstat from running, type
q
In the shell window in which you're logged in as root, place the call and request additional information from PPP by typing
ppp -r connectionname -d
The window in which you started isdnstat changes to show the progress of ISDN, and the window in which you typed the ppp command gives you information about PPP.
hostname: Unknown host
The above message means that the system you are trying to access does not appear in your /etc/hosts file.
To repair the error, add the system to the /etc/hosts file as described in “Setting Up a Host List” in Chapter 5.
If any of your physical devices are not working properly, run the appropriate confidence test. Follow these steps:
Choose “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.