10 Using the Problem Solving Tools

To help you resolve problems with network services, the operating system provides problem solving tools you can use to complete the following tasks:

Test a UUCP remote connection

Monitor a UUCP file transfer

Display the error log file

Display the syslogd daemon message files

The following sections contain information about using the tools associated with these tasks. For information about additional tools you can use to diagnose network connections and network hardware, see Network Administration: Connections.

10.1 Testing a UUCP Remote Connection

Testing a UUCP remote connection can help you diagnose certain UUCP problems; for example, to determine why there is a backlog of transfer requests in the queue.

To test a remote connection, do the following:

Log in as root.

Change to the /usr/lib/uucp directory by using the cd command.

Test the remote connection by using the uutry command, using the following syntax:
uutry system_name
The system_name variable names the remote system to contact.

Examine the debugging output; the last line contains the status of the transaction. If your local system establishes a connection to the remote system, the debugging output contains a good deal of information. You can press Ctrl/c to stop the uutry shell script.

The uutry command has the following characteristics:

It is a shell script stored in the /usr/lib/uucp directory.

It contacts a remote system with debugging turned on. If you are using the UUCP scheduler, uusched, to start the uucico daemon automatically at specified intervals, the uutry command overrides the retry time interval specified in the /usr/spool/uucp/.Status/system_name file.
If you use the uutry command frequently, you can put the pathname to the command in the PATH entry in your .profile file.

It directs debugging information to a file named /tmp/system_name, where system_name is the name of the local system. The uutry command then executes a tail -f command to display the file's contents.

If your local system cannot contact the remote system, do the following:

Validate the physical connections between the local and remote systems. At both systems, confirm that the computer is turned on, that all the cables are properly connected, that the ports are enabled, and the modems (if being used) are working. If the remote system is not at your physical location, contact the administrator of the remote system.

Verify all configuration files on both systems. Verify that all entries in the Devices, Systems, and Permissions files are correct. If you are using a modem, verify all entries in the Dialers and Dialcodes files.
If you are using a TCP/IP connection, verify that the configuration files contain the correct TCP entries. Verify that the inetd daemon can start the uucpd daemon. Edit the /etc/inetd.conf file and delete the comment character (#) from the beginning of the line containing the uucp entry. Restart the inetd daemon by using the following command:
```
# /sbin/init.d/inetd start
```

Always save the debugging output produced by the uutry command until you are certain that the problem is resolved.

The following example shows a successful test of a remote connection to system host6:

# /usr/lib/uucp/uutry host6
   
.
.
.
Conversation Complete: Status SUCCEEDED

The following example shows an unsuccessful test of a remote connection to system host6:

# /usr/lib/uucp/uutry host6
   
.
.
.
mchFind called (host6)
conn (host6)
getto ret -1
Call Failed: CAN'T ACCESS DEVICE
exit code 101
Conversation Complete: Status FAILED

10.2 Monitoring a UUCP File Transfer

Monitoring a UUCP file transfer enables you to diagnose other UUCP problems, especially if you can already establish a remote UUCP connection.

To monitor a file transfer, do the following:

Verify the status of the files in the spooling directory on your local system by using the uustat -q command.

Verify that the local system can contact the remote system by using the uutry system_name command.

If the debugging output indicates that the connection was not successful, follow the steps described in Section 10.1 to test the remote connection..

Prepare a file for transfer by using the uucp -r command. The -r option instructs the uucp utility to place the file in the queue without starting the uucico daemon.
Start the file transfer by using the uutry command.

See uutry(1) for additional information on this command.

The following example sends the test1 file to the system host6:

# uucp -r test1 host6! ~/test1
# /usr/lib/uucp/uutry host6

10.3 Viewing the Error Log File

To diagnose kernel and hardware errors, you can look at the system events that occurred prior to the errors. Messages from system events, such as error messages relating to the software kernel and system hardware, and informational messages about system status, startup, and diagnostics, are recorded in the binary error log file, /var/adm/binary.errlog.

Because this log file is in binary format, the operating system offers special utilities, Compaq Analyze and DECevent, that read the binary log file and run the data through a formatter to display the information. See ca(8) and dia(8) for more information about Compaq Analyze and DECevent, respectively.

Note that these utilities are not available in the operating system by default; you must install them separately.

Compaq Analyze is part of the Web-Based Enterprise Services (WEBES) kit, a suite of diagnostic utilities that is available for installation from the Associated Product CD-ROMs. For more information about the WEBES kit, see the following URL:

http://www.compaq.com/support/svctools/webes

DECevent is also available for installation from the Associated Product CD-ROMs, or you can download it from the web. For more information about the DECevent kit, see the following URL:

http://www.compaq.com/support/svctools/decevent

See the System Administration manual for information about using the Event Viewer to present errors as interpreted by Compaq Analyze and DECevent. Also, see uerf(8) for an alternative to these utilities.

10.4 Viewing the syslogd Daemon Message Files

You can use the syslogd daemon to help diagnose session layer problems such as access control problems for the Internet Protocol Version 4 (IPv4) and Internet Protocol Version 6 (IPv6).

The syslogd daemon starts running when you boot the system and whenever it receives a hangup signal. By default, it records the system messages for these events in a set of files in the /var/adm/syslog.dated directory (as specified in the /etc/syslog.conf file). The system messages can indicate error conditions or warnings, depending on the priority codes they contain.

Although it is possible to review the contents of the system message files from the command line, it is best to use the Event Viewer that is part of the SysMan Menu utility, because it simplifies access to the files and makes it easier for you to find particular problems.

To start the Event Viewer, invoke the SysMan Menu as decribed in Section 1.2.1, then select Monitoring and Tuning->View events. Alternatively, you can invoke the Event Viewer from a command line by entering the following command:

# /usr/bin/sysman event_viewer

Once the Event Viewer is displayed, you can use it to sort the log entries, filter the entries (for a certain event name, priority level, posting host, or date), and obtain more detailed information about individual entries.

For more information about event management and accessing the system log files, see evm(5), syslogd(8), the System Administration manual, and the online help.