Another useful feature is the ability to send messages to named pipes. This is done by preceding the name of the pipe by the pipe symbol (|). I find this a useful way of sending log messages to other programs, where I can process them further. Named pipes are created using the mkfifo(1) command and must already exist before syslogd starts up.
Another action is the ability to send messages to particular users, provided that they are logged in at the moment. To do this for a single user you need simply to put the user-name as the action. To send it to multiple users, separate the names by a comma. This might give you something like the following:
By using an asterisk in place of the list of usernames, you can send a message to everyone logged in.
In some cases, you want multiple actions for a specific facility or priority. This is no problem. You simply create multiple rules. One common example is broadcasting all of the emergency messages to every user, as well as writing them to a log file and sending them to another server in case the local machine crashes. This might be done like this:
*.emerg /var/adm/messages
*.emerg *
*.emerg @logserver
Previously, I mentioned the ability to cause a single action based on the same kind of message for multiple facilities. This is still an example of a single selector resulting in a specific action. Taking this one step further, you might want multiple selectors all to result in a specific action. Although it could be done with multiple rules, it is possible to have multiple selectors all on the same line. This is done by separating the selectors with a semicolon (;).
*.emerg;kernel.critical root,jimmo
This would notify the users root and jimmo of all emergency messages as well as critical messages from the kernel facility.
The Linux syslogd has added a couple of functions that are not available in other versions of Unix. By preceding a priority with an equal sign (=), you tell syslogd only to react to that one priority. This is useful because syslogd normally reacts to everything of that priority and higher. One place where this is useful is when you want all messages of priority debug to be logged to a specific file, but everything else logged to another file.
You can also explicitly exclude priorities by preceding them with an exclamation mark (!). Note that this will exclude the priorities listed as well as anything higher. You can combine the equal sign and exclamation mark to exclude a specific priority. If you do so, you need to precede the equal sign with the exclamation mark, since what you are saying is not to include anything that equals a particular priority.
All of these features can be combined in many different ways. For example, you can have multiple selectors, which include as well as exclude specific priorities. For example:
*.warn;mail.=info;lpr.none;uucp.!crit /dev/tty07
This would send warning messages from all priorities to the system console terminal /dev/tty7, plus the mail log messages at only the info priority, no printer messages at all, and all uucp messages except for the critical ones. Granted, this is a rather contrived example, but it does show you how complex you can get.
Note that multiple selectors on a single line can cause some confusion when there are conflicting components within a selector. The thing to keep in mind is that the last component takes precedence. In the previous example, we specified warning messages for all facilities and then overwrote portions of that for the mail, lpr, and uucp facilities.
Often, it is useful to log messages from scripts. This can done using the logger command (usually found in /usr/ bin). Without any options, it takes the username as the facility and notice as the priority. However, you can specify both a facility and priority from the command line by using the -p option. For example:
logger -p kern.warning The kernel has been recompiled.
This would send the specified message to the same place other kernel messages are sent. For details on the other options, see the logger(1)man page.