Solaris

Hi friends,
is it possible to ignore special messages with syslogd? we have some errors that are firmware issues an no real faults. we serach for a way to ignore ONLY these messages... OS is solaris 10...
any ideas?

tia,
DN2

Well after checking sunsolve. I think the clue is in syslog.h, mucking around with the facility numbers and syslog numbers(back up the file first) may give a workaround to your problem, I don't think it can help to filter off specific errors that you want.

what I understand after reading. I'm guessing

#define LOG_DAEMON (3<<3) /* system daemons */

will give errors but modifying

#define LOG_DAEMON (3<<6) /* system daemons */

may log to messages as info and not errors something like that

Anyway check this out and see if it has any value to you.

But share it here if you have a solution.



Document ID: 215965
Title: SYSLOG:Troubleshooting tips
Copyright Notice: Copyright © 2008 Sun Microsystems, Inc. All Rights Reserved
Update Date: Wed Mar 02 00:00:00 MST 2005
Solution Type Technical Instruction

Solution 215965 : SYSLOG:Troubleshooting tips


Functional Syslog Infodoc

This document provides a brief history of syslog, basic syslog troubleshooting tips, and expected behavior in common circumstances.

History of syslog

In Solaris[TM] 2.5.1 Maintenance Update, the syslogd daemon ran in a streams-based mode where all message requests were queued up into one pipe. The waiting requests were able to consume kernel memory while waiting for syslogd to send messages and consequently a panic would occur. There was also a limit of 20 uncommented lines in the syslog.conf.

Syslog was completely re-written for Solaris 2.6 to be multi-threaded and supported unlimited entries in the syslog.conf. Additionally, the limit on the number of uncommented lines in the syslog.conf was eliminated.

Solaris[TM] 7 introduced the concept of /dev/sysmsg, which can be used instead of /dev/console to route output from syslog to a variable set of console devices.

Backup the /etc/syslog.conf file

Always backup the file /etc/syslog.conf. If /etc/syslog.conf file is missing or corrupt, it can be copied from a Solaris cdrom.

The /etc/syslog.conf structure -facilities and levels

The general structure of the syslog.conf reflects a set of selectors (facility.level) and actions. The actions are generally the places to display or log the standard output. For example, in syslog.conf, there may be several things being sent to /dev/sysmsg and /var/adm/messages. This becomes important when trying to determine why something is not being sent to the console or to the messages file.

The /usr/include/sys/syslog.h file

Syslog facilities and levels are listed in the /usr/include/sys/syslog.h file. This file is for reference only, and should not be edited. The /usr/include/sys/syslog.h file contains numbers which correspond to each facility.

For example:

* Facility codes

*/

#define LOG_KERN (0<<3) /* kernel messages */
#define LOG_USER (1<<3) /* random user-level messages */
#define LOG_MAIL (2<<3) /* mail system */
#define LOG_DAEMON (3<<3) /* system daemons */
#define LOG_AUTH (4<<3) /* security/authorization messages */
#define LOG_SYSLOG (5<<3) /* messages generated internally by syslogd */
#define LOG_LPR (6<<3) /* line printer subsystem */
#define LOG_NEWS (7<<3) /* netnews subsystem */
#define LOG_UUCP (8<<3) /* uucp subsystem */
#define LOG_CRON (15<<3) /* cron/at subsystem */
/* other codes through 15 reserved for system use */
#define LOG_LOCAL0 (16<<3) /* reserved for local use */
#define LOG_LOCAL1 (17<<3) /* reserved for local use */
#define LOG_LOCAL2 (18<<3) /* reserved for local use */
#define LOG_LOCAL3 (19<<3) /* reserved for local use */
#define LOG_LOCAL4 (20<<3) /* reserved for local use */
#define LOG_LOCAL5 (21<<3) /* reserved for local use */
#define LOG_LOCAL6 (22<<3) /* reserved for local use */
#define LOG_LOCAL7 (23<<3) /* reserved for local use */

The extra LOG_ statement before the facility name is not meaningful in the context of this InfoDoc. There are 24 total facilities, 0-23. Facilities 9 through 14 are reserved for system use. Local facilities are 16-23 and are reserved for local use.

The definition of syslog levels 0-7 are as follows:

#define LOG_EMERG 0 /* system is unusable */
#define LOG_ALERT 1 /* action must be taken immediately */
#define LOG_CRIT 2 /* critical conditions */
#define LOG_ERR 3 /* error conditions */
#define LOG_WARNING 4 /* warning conditions */
#define LOG_NOTICE 5 /* normal but signification condition */
#define LOG_INFO 6 /* informational */
#define LOG_DEBUG 7 /* debug-level messages */

Together these facility codes and levels form the selectors in /etc/syslog.conf, such as KERN.INFO and AUTH.NOTICE. The KERN.INFO selector logs messages from the kernel which have a informational significance. The AUTH.NOTICE selector logs user authorization messages.

It may be thought that syslog daemon logs everything from every application and system process. This is definitely NOT the case. After a new Solaris installation, syslog will log the following:

*.err, kern.notice, and auth.notice are logged to the console.
*.err, kern.debug, daemon.notice, and mail.crit are logged to /var/adm/messages.
*.alert, kern.err, daemon.err messages will notify the operator.
*.alert messages will notify root.
*.emerg messages will notify all logged in users.

The commented lines in /etc/syslog.conf are *NOT* used.

A hostname can be specified in place of loghost, or the loghost alias can be defined in /etc/inet/hosts or in the name service. This will affect the way the ifdef statements are processed in /etc/syslog.conf. For more information, see InfoDoc # 17097.

Uses of syslog

Syslog is very configurable for system administrators. Many applications, including third-party software, can use syslog for logging messages. Some applications might log to syslog out of the box. Others may need to be configured to support logging through syslog.

Files used by syslog

/etc/syslog.conf - syslog configuration file

/etc/syslog.pid contains the syslog process ID

Editing /etc/syslog.conf

Note: The syslog.conf file is tab delimited. Problems can arise from using spaces in the file. See the man page on

It is important to consider available disk space when configuring /etc/syslog.conf. Log files can grow very rapidly. A separate /var filesystem, for example, on a separate partition from the root filesystem, will protect the system if /var fills up with message logs.

One of the more confusing aspects of editing syslog.conf involves specifying message levels. Specifying mail.err to go to /var/adm/messages causes mail.crit, mail.alert, and mail.emerg to also go to /var/adm/messages. In effect, selecting one level results in selecting all levels above it in urgency.

Starting and stopping the syslog daemon. Syslog starts when the machine is booted up.

Prior to Solaris[TM] 10, the commands to stop and start the syslogd daemon are:

# /etc/init.d/syslog stop
# /etc/init.d/syslog start

In Solaris 10, the commands to stop and start the syslogd daemon are:

# svcadm disable svc:/system/system-log:default
# svcadm enable svc:/system/system-log:default

Or, in Solaris 10, to restart the syslogd daemon and force it to reread /etc/syslog.conf:

# svcadm refresh svc:/system/system-log:default

Testing syslog configuration

The /usr/bin/logger command can be used for troubleshooting and manual logging. For example, to send a message of priority auth.notice, use the syntax:

# logger -p daemon.notice "test"

A tail of /var/adm/messages will show the test message:

# tail /var/adm/messages

Mar 1 17:01:52 persia jbrevik: [ID 702911 daemon.notice] test


Running syslog in debug mode

NOTE : To start the syslog service in debug mode for troubleshooting, see Infodoc 14542.