<

Workaround for dysfunctional multiple selectors in syslog

Published on
11,152 Points
5,152 Views
Last Modified:
Approved
Syslogd is a utility that traps and logs messages sent by running processes. It is configured with the syslog.conf file, which consists of lines containing a pair of fields: "the selector field which specifies the types of messages and priorities to which the line applies, and an action field which specifies the action to be taken if a message syslogd receives matches the selection criteria." (from the syslog.conf(5) man page). This is supposed to enable you to, for instance, focus certain logs on messages of high importance from a range of sources, focus other logs on a single function, and so on.

A longstanding fixture to the man page warns that the documented configuration rules do not always work:
Bugs
The effects of multiple selectors are sometimes not intuitive. For example "mail.crit,*.err" will select "mail" facility messages at the level of "err" or higher, not at the level of "crit" or higher.
To be more blunt, multiple selectors do not work correctly. For instance, the OS X server stock syslog.conf file contains the following directive:
*.notice;kern,authpriv,remoteauth,ftp,install.none;mail.crit          /var/log/system.log

Open in new window

That directive should result in the following messages being logged in system.log :
1. only messages of crit and above from the mail facility (mail.crit);
2. nothing from the kern, authpriv, remoteauth, ftp and install facilities (…install.none);
3. only messages of notice and above from all other facilities (*.notice).

In fact, the mail.crit part of the directive has no effect, nor does replacing it with any of the following, which should all work: mail.err; mail=>crit; mail=>err, etc. Despite the apparently correct selectors, messages from mail facility, in this case, are governed by the *.notice selector. Note that the mail selector is last, in this example, whereas it is first in the example in the man page. Evidently, neither order works.

This problem is not restricted to selectors involving the mail facility.

Fortunately, there seems to be a simple workaround. In the above example, deleting the mail.crit selector, and adding "mail" to the "none" selector, blocks mail messages from the system.log. You still want mail logging high level messages to system.log, however. This can be done with a second selector/action line for system.log:
*.notice;mail,kern,authpriv,remoteauth,ftp,install.none         /var/log/system.log
mail.err         /var/log/system.log

Open in new window

Although I have not found any sample syslog.conf files with a pair of lines like this, I have tested it in OS X server, and the selector on the second line works as expected.
0
Comment
Author:nxnw
0 Comments

Featured Post

Cloud Class® Course: Amazon Web Services - Basic

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.

Join & Write a Comment

This Micro Tutorial hows how you can integrate  Mac OSX to a Windows Active Directory Domain. Apple has made it easy to allow users to bind their macs to a windows domain with relative ease. The following video show how to bind OSX Mavericks to …
Learn the basics of Skype For Business in office 365

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month