test

System Administration Guide: Advanced Administration

Chapter 15 Managing System Messages

This chapter describes system messaging features in the Solaris Operating System.

Viewing System Messages

System messages display on the console device. The text of most system messages look like this:

[ID msgid facility.priority]

For example: 


[ID 672855 kern.notice] syncing file systems...

If the message originated in the kernel, the kernel module name is displayed. For example:


Oct 1 14:07:24 mars ufs: [ID 845546 kern.notice] alloc: /: file system full

When a system crashes, it might display a message on the system console like this:


panic: error message

Less frequently, this message might be displayed instead of the panic message: 


Watchdog reset !

The error logging daemon, syslogd, automatically records various system warnings and errors in message files. By default, many of these system messages are displayed on the system console and are stored in the /var/adm directory. You can direct where these messages are stored by setting up system message logging. For more information, see Customizing System Message Logging. These messages can alert you to system problems, such as a device that is about to fail.

The /var/adm directory contains several message files. The most recent messages are in /var/adm/messages file (and in messages.*), and the oldest are in the messages.3 file. After a period of time (usually every ten days), a new messages file is created. The messages.0 file is renamed messages.1, messages.1 is renamed messages.2, and messages.2 is renamed messages.3. The current /var/adm/messages.3 file is deleted.

Because the /var/adm directory stores large files containing messages, crash dumps, and other data, this directory can consume lots of disk space. To keep the /var/adm directory from growing too large, and to ensure that future crash dumps can be saved, you should remove unneeded files periodically. You can automate this task by using the crontab file. For more information on automating this task, see How to Delete Crash Dump Files and Chapter 8, Scheduling System Tasks (Tasks).

ProcedureHow to View System Messages

  1. Display recent messages generated by a system crash or reboot by using the dmesg command. 


    $ dmesg

    Or, use the more command to display one screen of messages at a time.


    $ more /var/adm/messages
Example 15–1 Viewing System Messages

The following example shows output from the dmesg command. 


$ dmesg
Jan  3 08:44:41 starbug genunix: [ID 540533 kern.notice] SunOS Release 5.10 ...
Jan  3 08:44:41 starbug genunix: [ID 913631 kern.notice] Copyright 1983-2003 ...
Jan  3 08:44:41 starbug genunix: [ID 678236 kern.info] Ethernet address ...
Jan  3 08:44:41 starbug unix: [ID 389951 kern.info] mem = 131072K (0x8000000)
Jan  3 08:44:41 starbug unix: [ID 930857 kern.info] avail mem = 121888768
Jan  3 08:44:41 starbug rootnex: [ID 466748 kern.info] root nexus = Sun Ultra 5/
10 UPA/PCI (UltraSPARC-IIi 333MHz)
Jan  3 08:44:41 starbug rootnex: [ID 349649 kern.info] pcipsy0 at root: UPA 0x1f0x0
Jan  3 08:44:41 starbug genunix: [ID 936769 kern.info] pcipsy0 is /pci@1f,0
Jan  3 08:44:41 starbug pcipsy: [ID 370704 kern.info] PCI-device: pci@1,1, simba0
Jan  3 08:44:41 starbug genunix: [ID 936769 kern.info] simba0 is /pci@1f,0/pci@1,1
Jan  3 08:44:41 starbug pcipsy: [ID 370704 kern.info] PCI-device: pci@1, simba1
Jan  3 08:44:41 starbug genunix: [ID 936769 kern.info] simba1 is /pci@1f,0/pci@1
Jan  3 08:44:57 starbug simba: [ID 370704 kern.info] PCI-device: ide@3, uata0
Jan  3 08:44:57 starbug genunix: [ID 936769 kern.info] uata0 is /pci@1f,0/pci@1,
1/ide@3
Jan  3 08:44:57 starbug uata: [ID 114370 kern.info] dad0 at pci1095,6460
.
.
.
See Also

For more information, see the dmesg(1M) man page.

System Log Rotation

System log files are rotated by the logadm command from an entry in the root crontab file. The /usr/lib/newsyslog script is no longer used.

The 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 MB 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 MB 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.

Customizing System Message Logging

You can capture additional error messages that are generated by various system processes by modifying the /etc/syslog.conf file. By default, the /etc/syslog.conf file directs many system process messages to the /var/adm/messages files. Crash and boot messages are stored here as well. To view /var/adm messages, see How to View System Messages.

The /etc/syslog.conf file has two columns separated by tabs:


facility.level ... action
facility.level

A facility or system source of the message or condition. May be a comma-separated listed of facilities. Facility values are listed in Table 15–1. A level, indicates the severity or priority of the condition being logged. Priority levels are listed in Table 15–2.

Do not put two entries for the same facility on the same line, if the entries are for different priorities. Putting a priority in the syslog file indicates that all messages of that all messages of that priority or higher are logged, with the last message taking precedence. For a given facility and level, syslogd matches all messages for that level and all higher levels.

action

The action field indicates where the messages are forwarded.

The following example shows sample lines from a default /etc/syslog.conf file. 


user.err                                        /dev/sysmsg
user.err                                        /var/adm/messages
user.alert                                      `root, operator'
user.emerg                                      *

This means the following user messages are automatically logged:

Note –

Placing entries on separate lines might cause messages to be logged out of order if a log target is specified more than once in the /etc/syslog.conf file. Note that you can specify multiple selectors in a single line entry, each separated by a semi-colon.

The most common error condition sources are shown in the following table. The most common priorities are shown in Table 15–2 in order of severity.

Table 15–1 Source Facilities for syslog.conf Messages

Source 

Description 

kern

The kernel 

auth

Authentication 

daemon

All daemons 

mail

Mail system 

lp

Spooling system 

user

User processes 

Note –

The number of syslog facilities that can be activated in the /etc/syslog.conf file is unlimited.

Table 15–2 Priority Levels for syslog.conf Messages

Priority 

Description 

emerg

System emergencies 

alert

Errors requiring immediate correction 

crit

Critical errors 

err

Other errors 

info

Informational messages 

debug

Output used for debugging 

none

This setting doesn't log output  

ProcedureHow to Customize System Message Logging

  1. Become superuser or assume an equivalent role.

    Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Edit the /etc/syslog.conf file, adding or changing message sources, priorities, and message locations according to the syntax described in syslog.conf(4).

  3. Exit the file, saving the changes.

Example 15–2 Customizing System Message Logging

This sample /etc/syslog.conf user.emerg facility sends user emergency messages to root and individual users.


user.emerg                                      `root, *'

Enabling Remote Console Messaging

The following new console features improve your ability to troubleshoot remote systems:

Using Auxiliary Console Messaging During Run Level Transitions

Keep the following in mind when using auxiliary console messaging during run level transitions:

Using the consadm Command During an Interactive Login Session

If you want to run an interactive login session by logging in to a system using a terminal that is connected to a serial port, and then using the consadm command to see the console messages from the terminal, note the following behavior:

ProcedureHow to Enable an Auxiliary (Remote) Console

The consadm daemon does not start monitoring the port until after you add the auxiliary console with the consadm command. As a security feature, console messages are only redirected until carrier drops, or the auxiliary console device is unselected. This means carrier must be established on the port before you can successfully use the consadm command.

For more information on enabling an auxiliary console, see the consadm(1m) man page.

  1. Log in to the system as superuser.

  2. Enable the auxiliary console. 


    # consadm -a devicename

  3. Verify that the current connection is the auxiliary console.


    # consadm
Example 15–3 Enabling an Auxiliary (Remote) Console


# consadm -a /dev/term/a
# consadm
 /dev/term/a

ProcedureHow to Display a List of Auxiliary Consoles

  1. Log in to the system as superuser.

  2. Select one of the following steps:

    1. Display the list of auxiliary consoles. 


      # consadm
/dev/term/a

    2. Display the list of persistent auxiliary consoles.


      # consadm -p
/dev/term/b

ProcedureHow to Enable an Auxiliary (Remote) Console Across System Reboots

  1. Log in to the system as superuser.

  2. Enable the auxiliary console across system reboots. 


    # consadm -a -p devicename

    This adds the device to the list of persistent auxiliary consoles.

  3. Verify that the device has been added to the list of persistent auxiliary consoles.


    # consadm
Example 15–4 Enabling an Auxiliary (Remote) Console Across System Reboots


# consadm -a -p /dev/term/a 
# consadm
/dev/term/a

ProcedureHow to Disable an Auxiliary (Remote) Console

  1. Log in to the system as superuser.

  2. Select one of the following steps:

    1. Disable the auxiliary console. 


      # consadm -d devicename

      or

    2. Disable the auxiliary console and remove it from the list of persistent auxiliary consoles.


      # consadm -p -d devicename

  3. Verify that the auxiliary console has been disabled.


    # consadm
Example 15–5 Disabling an Auxiliary (Remote) Console


# consadm -d /dev/term/a
# consadm