Troubleshooting Software Problems (Overview)

This chapter provides a general overview of troubleshooting software problems, including information on troubleshooting system crashes and viewing system messages.

This is a list of information in this chapter.

• "What's New in Troubleshooting Software Problems?"

• "Where to Find Software Troubleshooting Tasks"

• "Troubleshooting a System Crash"

• "Troubleshooting a System Crash Checklist"

• "Viewing System Messages"

• "Customizing System Message Logging"

What's New in Troubleshooting Software Problems?

This section describes features that are new in the Solaris 9 release.

New System Log Rotation

In Solaris 9 release, system log files are now rotated by the logadm command from an entry in the root crontab file. The /usr/lib/newsyslog script is no longer used.

The new system log rotation is defined in the /etc/logadm.conf file. This file includes log rotation entries for processes such as syslogd. For example, one entry in the /etc/logadm.conf file specifies that the /var/log/syslog file is rotated weekly unless the file is empty. The most recent syslog file becomes syslog.0, the next most recent becomes syslog.1, and so on. Eight previous syslog log files are kept.

The /etc/logadm.conf file also contains time stamps of when the last log rotation occurred.

You can use the logadm command to customize system logging and to add additional logging in the /etc/logadm.conf file as needed.

For example, to rotate the Apache access and error logs, use the following commands:

# logadm -w /var/apache/logs/access_log -s 100m
# logadm -w /var/apache/logs/error_log -s 10m

In this example, the Apache access_log file is rotated when it reaches 100 Mbytes in size, with a .0, .1, (and so on) suffix, keeping 10 copies of the old access_log file. The error_log is rotated when it reaches 10 Mbytes in size with the same suffixes and number of copies as the access_log file.

The /etc/logadm.conf entries for the preceding Apache log rotation examples look similar to the following:

# cat /etc/logadm.conf
.
.
.
/var/apache/logs/error_log -s 10m
/var/apache/logs/access_log -s 100m

For more information, see logadm(1M).

You can use the logadm command as superuser or by assuming an equivalent role (with Log Management rights). With role-based access control (RBAC), you can grant non-root users the privilege of maintaining log files by providing access to the logadm command.

For example, add the following entry to the /etc/user_attr file to grant user andy the ability to use the logadm command:

andy::::profiles=Log Management

Or, you can set up a role for log management by using the Solaris Management Console. For more information about setting up a role, see "Role-Based Access Control (Overview)" in System Administration Guide: Security Services.

New Fall Back Shell for root Account

If you changed root's shell to a non-existent shell in previous Solaris releases, you were forced to boot the system from a local CD or from the network and correct the root shell entry in the /etc/passwd file.

If you mistakenly provide a non-existent shell for root in the Solaris 9 release, root's shell will automatically fall back to /sbin/sh when one of the following occurs:

• You use the su command to change to the superuser (root) account.

• You are prompted for the root password at the single-user mode password prompt.

For more information, see su(1M).

Where to Find Software Troubleshooting Tasks

Troubleshooting a System Crash

If a system running the Solaris operating environment crashes, provide your service provider with as much information as possible, including crash dump files.

What to Do if the System Crashes

The most important things to remember are:

1. Write down the system console messages.

   If a system crashes, making it run again might seem like your most pressing concern. However, before you reboot the system, examine the console screen for messages. These messages can provide some insight about what caused the crash. Even if the system reboots automatically and the console messages have disappeared from the screen, you might be able to check these messages by viewing the system error log, the/var/adm/messages file. For more information about viewing system error log files, see "How to View System Messages".

   If you have frequent crashes and can't determine their cause, gather all the information you can from the system console or the /var/adm/messages files, and have it ready for a customer service representative to examine. For a complete list of troubleshooting information to gather for your service provider, see "Troubleshooting a System Crash".

   If the system fails to reboot successfully after a system crash, see Chapter 29, Troubleshooting Miscellaneous Software Problems (Tasks).

2. Synchronize the disks and reboot.

   ok sync

   If the system fails to reboot successfully after a system crash, see Chapter 29, Troubleshooting Miscellaneous Software Problems (Tasks).

Check to see if a system crash dump was generated after the system crash. System crash dumps are saved by default. For information about crash dumps, see Chapter 28, Managing System Crash Information (Tasks).