Browse All Articles > Workaround for dysfunctional multiple selectors in syslog
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:
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:
A longstanding fixture to the man page warns that the documented configuration rules do not always work:
BugsTo be more blunt, multiple selectors do not work correctly. For instance, the OS X server stock syslog.conf file contains the following directive:
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.
*.notice;kern,authpriv,remoteauth,ftp,install.none;mail.crit /var/log/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
Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.
Comments (0)